2012-03-13 14 views
5

Objective Cには、.NETでC#のような例外を処理する同等の方法があることが分かりました。 さらに、Appleのdocsによれば、例外を処理/処理してNSErrorオブジェクトを作成したいと思います。ドキュメントiOSでの例外処理の正しいアプローチは何ですか?

exception handlingに 「例外のさまざまな種類のキャッチ」セクションをよく見て撮影 ....私は、例外の種類をキャッチしたいと思います。 .NETでは、クラスメソッドのドキュメントを参照して発生可能な例外を取得するのに使用されています。 apple-docsからこの情報を入手するには? -method/object/process-でどのような例外が発生する可能性がありますか?ご提案のための

おかげ

トム

答えて

5

Appleのドキュメントによれば、例外的な状況ではほとんどの例外がスローされます。 (一部の例外は、NSArray境界からオブジェクトにアクセスするようなものではありません。)

.NETはローカル例外処理を推奨します。 Cocoaは、大規模な例外処理を促進するために書かれています。 .NETでローカル例外処理を行う理由は、一部の部分が予期せぬ方法で失敗することが予想されるためです(何かをダウンロードする際のネットワークエラーなど)。 Cocoaでは、代わりにNSErrorsを返すメソッドを使用してこれを処理します。これは同じことですが、メソッドのシグネチャでのみ見えます。

大まかに言うと、Cocoaは回復方法が不明な場合にのみ例外をスローします。 (これは.NETののように例外が投げられるのを間違えてはいけません)。

+0

あなたの入力に感謝! – Tom

2

developer reference for exception handlingを見てください。ココアでは、nilArgumentExceptionのような例外はありません。NSExceptionしか取得できません。きめ細かいメッセージを与えるか、またはあなたが次のことを行うことができます扱うために、

以下
if ([[exception name] isEqualToString:MyAppException]) 

はNSExceptionヘッダーファイルで定義された例外の名前の一覧です。

FOUNDATION_EXPORT NSString * const NSGenericException; 
FOUNDATION_EXPORT NSString * const NSRangeException; 
FOUNDATION_EXPORT NSString * const NSInvalidArgumentException; 
FOUNDATION_EXPORT NSString * const NSInternalInconsistencyException; 

FOUNDATION_EXPORT NSString * const NSMallocException; 

FOUNDATION_EXPORT NSString * const NSObjectInaccessibleException; 
FOUNDATION_EXPORT NSString * const NSObjectNotAvailableException; 
FOUNDATION_EXPORT NSString * const NSDestinationInvalidException; 

FOUNDATION_EXPORT NSString * const NSPortTimeoutException; 
FOUNDATION_EXPORT NSString * const NSInvalidSendPortException; 
FOUNDATION_EXPORT NSString * const NSInvalidReceivePortException; 
FOUNDATION_EXPORT NSString * const NSPortSendException; 
FOUNDATION_EXPORT NSString * const NSPortReceiveException; 

FOUNDATION_EXPORT NSString * const NSOldStyleException; 

CORRECTION:カスタム例外をキャッチするために、以下のコメントの1で提案されているように

あなたは、NSExceptionクラスをサブクラス化することができます。

+1

NSExceptionをサブクラス化し、独自のコードの '@ catch'ブロックで特定の型をキャッチすることは、何もありません。 –

+0

お返事ありがとうございます – Tom

+0

@GrahamLee。あなたはとても正しいです。あなたは間違いなく拡張することができます。また、あなたのブログに従って開始:) – Vignesh

5

Objective-Cの世界でのエラー処理は、おそらくあなたとはまったく異なっています。まもなく言いたいことは、例外を忘れることです。ほとんどのエラーは、戻り値またはNSError*へのポインタを渡すことによって処理されます。

NSErrror *error = nil; 
BOOL success = [somebody doSomethingWithError:&error]; 
if (!success) { 
    NSLog(@"Got error: %@", error); 
} 

と呼び出し先側:

- (BOOL) doSomethingWithError: (NSError**) error 
{ 
    error = error ? error : &(NSError*){ nil }; 
    if (somethingWentWrong) { 
     *error = [NSError …]; 
     return NO; 
    } 
    // All is fine 
    return YES; 
} 

これは面倒なように見えますが、実際にはほとんどが正常に動作します。まれに、実際に何か例外が発生することがあります([NSFileHandle writeData:]など)。ドキュメントにはその事実が記載されていますが、他の言語では例外的に分析するとは思われません。

+0

こんにちはzoul、あなたの答えに感謝します。 >これは私のプロジェクトのすべてのコードを見越してtry&catchブロックを構築することです(NULL値をチェックするのと同じように、何かを正しく処理するのを忘れた場合に備えて)。ソフトウェアがクラッシュするのを防ぎます。そうでなければ、私は開発に携わり、例外処理については心配しないでください。 - 私のメインメソッドの周りにtryとcatchブロックを作成します。なぜなら、未処理の例外がそこに終わるからです(そして、それをログに記録したり、ユーザにメッセージを提示します)。 – Tom

+0

Objective- Cでは、 'nil'オブジェクトにメッセージを送ることは合法です。それはときどきいい時間を節約し、時には素晴らしいバグが起きるのを待っています。 Objective-Cではtry/catchブロックを忘れることがほとんどです。失敗する可能性のあるものを呼び出すときは、エラーがどのように返されるかを見てください。ほとんどの場合、メソッドのシグネチャから明らかなように、 'NSError'が返されます。残りの少数のケースでは、メソッドによってスローされる可能性があることがドキュメントからわかるため、そこにtry/catchブロックが必要です。このような状況もまれです。 – zoul

+0

あなたのご意見ありがとうございました! – Tom

関連する問題