一部の友人は、アプリの実装を終えたばかりで、カスタム例外を使用しています。私の注意を引いたのは、カスタム例外が発生したときに、実装した例外基本クラスのコードに例外を記録したことです。だから私の質問は、これは良い設計アプローチですか?. 私の考えでは、ロギングヘルパーの方が使いやすいです
public class BaseCustomException: System.Exception
{
public BaseCustomException()
{
TightlyCoupledClass.Log(this);
}
}
いいえ、これは恐ろしいアプローチです。その理由は、作成されるすべての例外がスローされるという前提があるためです。これは絶対に当てはまりません。
通常、例外は読み取り専用であるため、特定の状況に対して 1 つの例外が作成され、必要に応じて再スローされる実装があります (CLR は、構築時ではなく、例外がスローされたときに StackTrace を設定します)。
要するに、それは一般的ではありませんが、作成時に例外がスローされない可能性があり、それに基づいて仮定を行うべきではありません。
CustomException の例外がスローされるたびにロギングが行われることを保証できるように、これを配置するという彼らの考えを理解しています。ただし、これは間違いなく臭いコードです。
例外は例外に対してのみ使用する必要があり、 CustomException がスローされる可能性のあるコードを実行するコードは、その例外をどうするか、それをログに記録するかどうかを決定できる必要があります...ログは固有でなければならないためですそれが引き起こされたシナリオに。
余談ですが、カスタム例外は ApplicationException からルートとして継承する必要があります。これにより、例外がビジネス ライブラリのカスタムか、.NET フレームワーク自体のカスタムかがわかります。-- 訂正 --本質的に ApplicationException を使用すると役に立たないことを認識していなかったこの投稿
を
見つけました。
私はそうは思わない。例外 (およびその他のデータ) をログに書き込むグローバル例外ハンドラーを設定します。そうすれば、キャッチされた例外のみを記述できます。
コンストラクター内でのログ記録は明らかに厄介です。操作を試みていたコードが、例外を含む可能性のある意味のあるメッセージを構築することになっているのは、他にどのような方法があるでしょうか? 例外の役割は、メッセージを記録することではなく、問題を表すことです。他のコードは、その特定の例外をキャッチできるすべての部分が必要なことを実行できるように、それを処理する必要があります。これには、例外のログ記録が含まれる場合と含まれない場合があります。
コンストラクター内のログの場合、例外がラップされ、再スローされて再度キャッチされると、例外が 2 回ログに記録されます。これはばかげています。
catch ( CustomException exception ){
Logger.error( "Really useful message", exception );
}
このソリューションは結合が強すぎて、構成できません。Enterprise Library Exception Handling Application Blockなど、より堅牢な例外処理フレームワークを使用することをお勧めします。