エラー処理や例外処理の使用場所を理解できません。私はこれを前提としています。もしそれが既存のフレームワーククラスであれば、デリゲートメソッドがあり、プログラマーがエラーオブジェクト参照を送信し、その後エラーを処理するのを容易にします。例外処理は、いくつかのフレームワーククラスを使用するプログラマの操作がエラーをスローし、エラーオブジェクトの参照に関する修正を取得できない場合です。エラー処理と対象処理の例外処理の比較
この仮定は有効ですか？どのように私はそれらを理解する必要がありますか？
プログラマが例外をスローするメソッドのパラメータをチェックすると、表示されないエラーに対して例外を使用する必要があります。例えば。 NSArraysから得られる0またはよく知られた "out of bounds" - 除算で除算します。
NSErrorsは、プログラマが何もできないエラーに対するものです。例えば。 plistファイルを解析します。プログラムがその内容を読み取ろうとする前に有効なplistであるかどうかをチェックすると、リソースの無駄になります。妥当性チェックでは、プログラムはファイル全体を解析する必要があります。また、ファイルを解析して有効であると報告すると、再度解析することができます。したがって、このメソッドは、ファイルを解析できない場合は、NSError（または何も問題がないことを示す、単にnil）を返します。
有効性の解析は、「プログラマがパラメータをチェックしているはずです」という部分です。このタイプのエラーには適用できないため、例外をスローしません。
理論上は、範囲外の例外をreturn nilに置き換えることができます。しかし、これは非常に悪いプログラミングにつながります。
Apple言う：
重要：多くの環境では、例外の使用はかなり一般的です。たとえば、ファイルが見つからない、またはデータを正しく解析できなかった場合など、ルーチンが正常に実行できなかったことを知らせる例外をスローすることがあります。例外はObjective-Cではリソース集約型です。一般的なフロー制御には例外を使用しないでください。単純にエラーを示すことはできません。その代わりに、エラーが発生したことを示すためにメソッドまたは関数の戻り値を使用し、エラーオブジェクトの問題に関する情報を提供する必要があります。
私はあなたがエラーについてのあなたの前提に完全に合っていると思うし、そのフレームワークは一連のメソッド（UIWebViewエラー処理）を提供すると思いますが、例外は例外的にしか発生しないため、フレームワークによって許可され、修正することができます。 （例えば、配列のメンバーに限度を超えてアクセスするなど）。 となり、アプリケーションがクラッシュする可能性があります。