私はそれを認めます: 私はあまり多くの例外処理を気にしません. もっとやらなければならないことはわかっていますが、どこから始めてどこでやめるべきかについて頭を悩ませることはできません。私は怠惰ではありません。それからはほど遠い。それは、私が例外処理のアンビバレンスに悩まされているということです。最小のアプリでも、例外処理を適用できる場所は無数にあるように思われ、やり過ぎのように感じ始める可能性があります。
私は注意深くテストし、検証し、黙祷を捧げてきましたが、これは悪いプログラミング事故が起こるのを待っています。
では、例外処理のベスト プラクティスは何ですか? 特に、例外処理を適用する必要がある最も明白で重要な場所はどこですか? また、例外処理を考慮する必要がある場所はどこですか?
あいまいな質問で申し訳ありませんが、これで本を完全に閉じたいと思います。
Microsoft のPatterns & Practices チームは、Enterprise Library Exception Handling Application Blockに例外管理のベスト プラクティスをうまく取り入れました。
Enterprise Library を使用しない場合は、ドキュメントを読むことを強くお勧めします。P&P チームは、例外処理の一般的なシナリオとベスト プラクティスについて説明します。
開始するには、次の記事を読むことをお勧めします。
ASP.NET 固有の記事:
例外処理の黄金律は次のとおりです。
「扱い方を知っているものだけを捕まえる」
キャッチが何もせずに例外を再スローする try-catch ブロックが多すぎます。これでは何の価値もありません。例外をスローする可能性があるメソッドを呼び出したからといって、呼び出し元のコードで例外を処理する必要があるわけではありません。多くの場合、何をすべきかを知っている他のコードに例外をコール スタックまで伝搬させることは完全に許容されます。場合によっては、例外をユーザー インターフェイス レイヤーまで伝搬させてから、メッセージをキャッチしてユーザーに表示することが有効です。状況を処理する方法を知るのに最適なコードがなく、ユーザーが一連のアクションを決定する必要がある場合があります。
最初に、すべての例外をキャッチし、ユーザーにとってやや不親切なメッセージを出力する適切なエラー ページを追加することをお勧めします。例外について利用可能なすべての詳細を記録し、それを修正してください。これを行ったことをユーザーに知らせ、(おそらく) 機能するページへのリンクをユーザーに提供します。
次に、そのログを使用して、特別な例外処理を配置する必要がある場所を検出します。何かを行う予定がない限り、例外をキャッチしても意味がないことに注意してください。上記のページが整っている場合、その特定の時点で回復するための特定の方法がない限り、すべてのデータベース操作でデータベース例外を個別にキャッチしても意味がありません。
覚えておいてください: 例外をキャッチしないことよりも悪いことは、例外をキャッチして何もしないことだけです。これは本当の問題を隠すだけです。
http://code.google.com/p/elmah/などのグローバル例外ハンドラから始めます。
次に、どのような種類のアプリケーションを作成し、どのようなユーザー エクスペリエンスを提供する必要があるかという問題が生じます。ユーザー エクスペリエンスが充実していればいるほど、より優れた例外処理を提供する必要があります。
例として、ディスク クォータ、ファイルサイズの制限、画像のサイズの制限などがある写真ホスティング サイトを考えてみましょう。エラーごとに、単に「エラーが発生しました。もう一度お試しください」を返すことができます。または、詳細なエラー処理に入ることができます。
などなど
例外処理に万能のサイズはありません。
ASP.NET固有のものよりも、一般的な例外処理に関するものかもしれませんが：
非常に基本的なレベルでは、Global.asax ファイルで HttpApplication.Error イベントを処理する必要があります。これにより、発生したすべての例外が 1 つの場所に記録されるため、例外のスタック トレースを確認できます。
この基本的なレベルとは別に、例外から回復できることがわかっている例外を処理するのが理想的です。たとえば、ファイルがロックされている可能性があると予想される場合は、IOException を処理し、ユーザーにエラーを報告することをお勧めします。