結局のところ、仕事をするためにどのツールが必要かということです。
例外は非常に強力なツールです。それらを使用する前に、このパワーとそれに伴う複雑さが必要かどうかを尋ねてください。
例外のある行にヒットするとすべてが停止することがわかっているため、例外は単純に見えるかもしれません。ここからどうなりますか？
キャッチされない例外は発生しますか?
例外はグローバル エラー処理によって捕捉されますか?
例外は、よりネストされた詳細なエラー処理によって処理されますか?
その例外が何をするかを知るには、スタックのすべてを知る必要があります。これは、独立の概念に違反しています。そのメソッドは、エラー処理に依存して、期待どおりに動作するようになりました。
メソッドがある場合、そのメソッドの外にあるものを気にする必要はありません。入力が何であるか、それを処理する方法、および応答を返す方法だけを気にする必要があります。
あなたが本質的に言っている例外を使用するとき、私はここから何が起こるかは気にしません。
エラーの処理方法が気になる場合は、もう少し考えて、それをメソッドのインターフェイスに組み込みます。たとえば、オブジェクトを見つけようとしている場合、オブジェクトが見つからない場合は、そのオブジェクトのデフォルトを返す可能性があります。 「オブジェクトが見つかりません」のような例外をスローするよりも。
エラー処理をメソッド インターフェイスに組み込むと、そのメソッドのシグネチャがそのメソッドの機能をより明確にするだけでなく、メソッドの呼び出し元にエラーを処理する方法の責任が課せられます。呼び出し元のメソッドはそれを処理できる場合とできない場合があり、そうでない場合はチェーンを再度報告します。最終的に、アプリケーションのエントリ ポイントに到達します。アプリケーションのパブリック インターフェイスを使用している場合は、例外がどのように処理されるかをよく理解しているため、ここで例外をスローするのが適切です。
Web サービスのエラー処理の例を挙げましょう。
レベル 1. global.asax でのグローバル エラー処理 - これは、キャッチされない例外を防ぐセーフティ ネットです。これは、意図的に達成されるべきではありません。
レベル 2. Web サービス メソッド - json インターフェースに常に準拠することを保証するために、try/catch にラップされます。
レベル 3. ワーカー メソッド - データを取得して処理し、そのまま Web サービス メソッドに返します。
ワーカー メソッドで例外をスローするのは適切ではありません。はい、Web サービス メソッドのエラー処理をネストしましたが、そのメソッドは、これが存在しない可能性がある他の場所で使用できます。
代わりに、ワーカー メソッドを使用してレコードを取得し、レコードが見つからない場合は、単に null を返します。Web サービス メソッドは応答をチェックし、null を検出すると、続行できないことを認識します。Web サービス メソッドは、json を返すエラー処理があることを認識しているため、例外をスローすると、何が起こったかの詳細が json で返されます。クライアントの観点からは、簡単に解析できる json にパッケージ化されたことは素晴らしいことです。
各ピースが何をする必要があるかを知っていて、それを実行していることがわかります。ミックスで例外をスローすると、アプリケーション フローがハイジャックされます。これにより、コードの追跡が困難になるだけでなく、例外の悪用に対する応答が try/catch になります。これで、別の非常に強力なツールを悪用する可能性が高くなります。
アプリケーションの途中で try/catch がすべてをキャッチしているのをよく見かけます。これは、使用するメソッドが見た目よりも複雑であることに開発者が恐れたためです。