コード内の未処理の例外を検出するツールがあります: Exception Hunter by Red Gate software。
結局のところ、彼らはそれを中止しました:
.NET 4.0 と WPF のリリースにより、CLR がスローできる例外の数が大幅に増加し、圧倒されるほどになりました。除外リストは、CLR がスローする可能性が低いすべての例外をカバーすることはできなくなりました。つまり、Exception Hunter は正確な結果を提供しますが、これらの結果には潜在的な例外の長いリストが含まれ、そのほとんどは心配する必要がありません。
これは、「メソッドがスローできるすべての例外をキャッチする」ことが悪い考えである可能性があることを示しているはずです。通常のパターンは、グローバルなキャッチオールを持つことです
try {
...
} catch (Exception ex) {
logAndShowErrorMessage(ex);
}
ユーザー インターフェイス (WinForms) のトップレベルでのみ、または専用メソッド (WPF: Application.DispatcherUnhandledException、WebForms: Application.Error ) でエラーを処理します。
この例外の発生が予想される例外的なケースでのみ、例外をコードで直接処理し、この例外を具体的に処理する方法と、その後プログラムの実行を続行する方法を知っています。
補足として: あなたが望むものは、" checked exceptions "と呼ばれる Java 機能と非常によく似ています: 例外を処理するか、メソッドが例外を再スローすることを宣言する必要があります。次の質問は、C# の設計者が意図的にこの機能を含めないことを選択した理由を説明しています。