c# - 例外処理は、すべての関数に対してトップレベルで実行されます

Question

例外処理のいくつかのアプローチを見てきました。私が見た最も一般的な 2 つのパターンは次のとおりです。

• すべての関数でキャッチを試み、例外をログに記録して再スローします
• 最上位レベルでキャッチを試み（メイン関数と同様）、例外をログに記録して再スローします

ある場合、どちらがより良い習慣ですか？または、どのような状況で、あるアプローチを別のアプローチよりも選択しますか?

Answer 1

これはアプリケーションに依存し、設計上の選択ですが、オプション 1 は非常に厄介です。恣意的にすべてをキャッチするのではなく、何らかの方法で処理する準備ができている例外のみをキャッチする必要があります。ほとんどの言語では、例外にはスタック トレースが表示されるため、すべてのレベルでログを記録する必要はありません。ログに記録して再スローする、またはログに記録するなどの方法で処理すると、ユーザーにエラーを通知し、実行を続行します

補足として、例外をコード内のロジックとして使用しないでください。フロー制御として try catch ブロックを使用していることに気付いた場合は、再設計を検討する必要があります。例外はまさに例外的です。

Answer 2

オプション 1 は悪い方​​法と見なされ、避ける必要があります。オプション 2 は従うべきベスト プラクティスです。

例外処理の原則は、デフォルトでは例外を自然にスローし、オプション 2 のように最上位でキャッチすることです。例外をキャッチする必要があるのは、例外に基づいてビジネス ロジックを実行する場合だけです。ビジネス ロジックを処理しない場合は、キャッチしないでください。

オプション 1 のその他の短所:

1. 多くのtry-catchとre-throwは、コードを読みにくくします。

2. すべてのメソッドで例外をキャッチすることを考えてログに記録すると、ログ ファイルに同じ例外情報が記録されますが、これは必要ありません。

Answer 3

私がよく見た練習は次のとおりです。

処理する準備ができている例外をキャッチします。たとえば、重複した主キーの挿入、それをキャッチし、レコードに固有のものを入力するようにユーザーに適切なメッセージを表示します。

アプリケーションの残りの部分では、ライブラリでの例外処理はありません。そのため、例外が発生した場合、適切な処理が行われる上位層にポップされる可能性があります。

次の記事が表示される場合があります: .NET での例外処理のベスト プラクティス

Answer 4

例外が通過したすべての関数を実際にログに記録する価値がないため、通常はオプション 1 を完全に回避します。通常、主に例外が発生した場所に関心があります。どのようにしてそこに到達したかについて正確なフローを知る必要がある場合もありますが、それは例外コール スタックから取得できます。

私が例外を処理するために使用する原則は、私が何かをしている場合にのみ例外をキャッチすることです。キャッチの唯一の目的が再スローである場合、それをキャッチしても意味がありません。ただし、それをキャッチしてログに記録し、カスタム固有の例外でラップし、たとえば処理する場合、それは十分な理由です。通常、そのようなタスクはすべての機能で行われるわけではなく、レイヤー/層の境界で行われることが最も一般的です。