現在、winforms アプリケーション (C#) を作成しています。
私が見ることができるかなり標準的なアプローチに従って、Enterprise Library Exception Handling Block を利用しています。IE : Program.cs の Main メソッドで、イベント ハンドラーを Application.ThreadException イベントなどに接続しました。
このアプローチはうまく機能し、アプリケーションの例外的な状況を処理します。
ビジネス オブジェクトの 1 つで、オブジェクト プロパティの 1 つの Set アクセサーでさまざまな例外をスローします。
set {
if (value > MaximumTrim)
throw new CustomExceptions.InvalidTrimValue("The value of the minimum trim...");
if (!availableSubMasterWidthSatisfiesAllPatterns(value))
throw new CustomExceptions.InvalidTrimValue("Another message...");
_minimumTrim = value;
}
このアプローチの私のロジックは (これを「いつ例外をスローするか」の議論に変えることなく)、単純に、ビジネス オブジェクトはビジネス ルールの制約をチェックし、必要に応じてバブルアップしてキャッチできる例外をスローする責任があるということです。私のアプリケーションのUIでは、パブリックプロパティが設定されている値を明示的にチェックします(そして、フレンドリーなダイアログなどを表示するアクションを実行します)が、例外をスローすることで、ビジネスオブジェクトが存在する状況もカバーしていることに注意してくださいUI では使用できない場合があります。たとえば、プロパティが別のビジネス オブジェクトによって設定されている場合などです。とにかく、皆さんの考えは理解できると思います。
私の問題は、これらの例外が Application.ThreadException に接続されたハンドラーによってキャッチされていないことであり、その理由がわかりません。
他の読書から、私は Application.ThreadException イベントを実行しましたが、それは「... メイン GUI スレッドで発生した例外をキャッチします」。ビジネス オブジェクトで発生している例外は、このスレッドではありませんか? 新しいスレッドは作成していません。
次のようにコードを更新し、Application.ThreadException に接続されているイベント ハンドラーを明示的に呼び出すと、このアプローチを機能させることができます。これは、Enterprise Library のサンプルで概説されているアプローチです。ただし、このアプローチでは、最初に「グローバル」ハンドラーを使用して回避しようとしていた、try catch でスローされた例外をラップする必要があります。
try
{
if (value > MaximumTrim)
throw new CustomExceptions.InvalidTrimValue("The value of the minimum...");
if (!availableSubMasterWidthSatisfiesAllPatterns(value))
throw new CustomExceptions.InvalidTrimValue("Another message");
_minimumTrim = value;
}
catch (Exception ex)
{
Program.ThreadExceptionHandler.ProcessUnhandledException(ex);
}
また、ハンドラーを AppDomain.UnhandledException イベントまで配線して調査しましたが、これも例外をキャッチしません。
最初のコード サンプルで、例外がグローバル例外ハンドラーによってキャッチされない理由を誰かが説明してくれれば幸いです。不足している別のアプローチはありますか、または必要に応じて、上記のように try catch でコードをラップすることに固執していますか?