8

例外の使用とNSErrorの使用に関する Apple の推奨事項を読みました。

また、例外を使用するかどうかを議論する同様のスタックオーバーフローの質問をいくつか読みました。

iOS での例外処理

Objective-C での例外の使用

Objective-C の例外

iOS のエラー通知/処理方法として例外を使用することの長所と短所を理解しようとしています (率直に言って、私は Apple の文に満足していません (何をすべきかは述べていますが、なぜそうするべきかは述べていません):

範囲外のコレクション アクセス、不変オブジェクトの変更の試行、無効なメッセージの送信、ウィンドウ サーバーへの接続の切断など、プログラミングまたは予期しないランタイム エラーのために、例外の使用を予約する必要があります。通常、実行時ではなくアプリケーションの作成時に例外を除いて、この種のエラーに対処します。

例外使用の利点:

  • エラー生成コードとエラー処理コードの間のすべての中間コードを変更する必要はありません

  • メソッドの引数と戻り値を汚染しません

短所：

  • 手動で管理されるすべてのメモリ コードについては、特に注意する必要があります (リソースが確実に解放されるように、自動解放オブジェクトでラップする必要があります)。

  • コードとフレームワークの境界に注意する必要があります。例外がコードから離れた場合、問題が発生する可能性があります (フレームワークがメモリを手動で管理する可能性があるため)。

何か見逃しましたか？追加の短所/長所はありますか?

ライブラリのようなコードでは例外が問題ないように見えます (非常に大量の密にパッケージ化されたコードがあり、外部システム/フレームワークとあまり通信しない場合)。また、積極的にコードに例外を使用するのは難しいようです。他のフレームワークと相互作用します。

あなたの経験はこの理論を証明していますか?

この件に関する追加情報をいただければ幸いです。

4

1 に答える 1

13

tl;dr 例外は、致命的/回復不能/プログラマー エラーに対してのみ使用する必要があります。これらを Java またはその他の例外が回復可能な環境で使用しようとすると、コードがより脆弱になり、保守が難しくなり、リファクタリングが難しくなり、システム フレームワークを活用する能力も制限されます。

短所: コードでフロー制御および/または回復可能なエラーの例外を使用する場合、コードは設計上、Apple の設計パターンとは異なります。

最終結果？

•コードと Apple の API との間の境界が常に例外動作を分離しない限り、コードで Apple の APIをまったく使用することはできません。

• リファクタリングのたびに、大量の例外処理コードをリファクタリングする必要があります

• 些細なことの多くが非常に複雑になります。たとえば、オブジェクトを列挙可能なコレクションに入れ、その列挙なしでそれらを列挙することはできません-ブロック、forループ、何でも...-また、境界で例外処理を行います。

検討：

 NSArray *a = @[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];

@try {
    for(id k in a) { [k doSomething]; }
} @catch(...) {
}

何らかの理由で発生する可能性がある場合doSomething、上記はフレームワークの文書化された設計パターンに違反しています。これは、Apple のフレームワーク内のフレーム間で例外をスローするためです。

それは1つの強力な大きな欠点です。プロのセットがそれを上回るとは思えないほど大きい.

于 2012-10-02T18:10:02.047 に答える