.NET では、メソッド シグネチャは、コードによってスローされる可能性のあるいくつかの例外の処理に失敗したかどうかを教えてくれません。HashTable remove を使用しているが、ArgumentNullException を処理していない場合、警告できるツールはありますか? 実行時に驚かせたくありません。
これは、コードを十分に理解する必要があるということでしょうか。
.NET では、メソッド シグネチャは、コードによってスローされる可能性のあるいくつかの例外の処理に失敗したかどうかを教えてくれません。HashTable remove を使用しているが、ArgumentNullException を処理していない場合、警告できるツールはありますか? 実行時に驚かせたくありません。
これは、コードを十分に理解する必要があるということでしょうか。
実際には、プログラムを終了して予期しない例外を処理することが、この状況に対処する最善の方法です。一般に、予期しないことが発生した場合、プログラムの状態は定義されていないためです。すべての例外をログに記録し、適切な受け入れテストのセットを用意すれば、プログラム フローに起因する予期しない例外から生じる問題を排除できます。
メソッド入力のチェック、クラスの単体テスト、およびフレームワークの理解による防御的プログラミングにより、ほとんどの例外が予想されます。
Windows アプリケーションの場合:
AppDomain currentDomain = default(AppDomain);
currentDomain = AppDomain.CurrentDomain;
// Handler for unhandled exceptions.
currentDomain.UnhandledException += UnhandledExceptionHandler;
// Handler for exceptions in threads behind forms.
Application.ThreadException += ThreadExceptionHandler;
public static void UnhandledExceptionHandler(object sender, UnhandledExceptionEventArgs e)
{
}
public static void ThreadExceptionHandler(object sender, Threading.ThreadExceptionEventArgs e)
{
}
あなたが達成しようとしていることに対する言語サポートはありません。VS にカスタム アドインを作成して、API のすべてのエントリ ポイントにロギング用の try catch があることを確認しました。ただし、エラーで意味のあることを行うにはコードを記述する必要があるため、宣言された可能性のあるすべての例外ケースをカバーすることを強制する言語の価値は見たことがありません。ほとんどの人は、コンパイラが不平を言っていることを見て、ハンドラーを書き、役に立たないコードで役立つエラーを隠します。場合によっては、失敗して問題があることがわかっている方がよい場合もあります。
アプリケーションの最上位レベルの例外ハンドラーを追加し、アプリのユニット、機能、および統合テストを記述して、考えられるすべてのユース ケースをテストする必要があります。これにより、ほとんどすべての未チェックの例外を排除できます。
また、例外をキャッチしないようにしますが、理由を排除してください。(つまり、キャッチArgumentNullException
しないがパスしないnull