例外が発生し、それを試行/キャッチしなかったメソッドでデバッガーでコードがクラッシュするのを見ることほどイライラすることはありません。
ソースをスキャンして、例外をスローする可能性のあるすべての関数にタグを付ける簡単な方法はありますか?
ビジュアルアシストの組み込みには、これらの機能を特定の色で着色する隠しオプションがありますか?
ありがとう
R
最も単純なコードを除くすべてのコードで例外がスローされる可能性があります (少なくともメモリ不足)。コードのどのセクションが例外をスローするかどうかを細かく管理しようとするよりも、少なくともグローバルな try/catch を使用して、防御的にコードを作成する方がおそらく良いでしょう。
いいえ、これを自動的に行う方法はなく、メソッドによってスローされる可能性のあるすべての例外のリストを取得する良い方法もありません。ここにいくつかの理由があります
redgate にはこの「例外ハンター」用のツールがあると思います。試用後に料金が発生します。
他の人が言ったように、チェックされた例外をサポートしていないため、C# でこれを行うための簡単な方法を見つけることができるかどうかはわかりません。
ちょっと余談ですが、これは Anders Hejlsberg とのインタビューで「チェックされた例外の問題」について話していることを思い出しました。チェックされた例外を炎上させようとしているわけではありませんが、C# の例外設計の背後にある Ander の理論的根拠と、例外を処理するための提案された方法である集中例外処理を読むことをお勧めします。
他の人が言ったように、できないことが証明されていない限り、コードのすべての行が例外をスローできると想定する必要があります。より良い質問は、「それについて何をするつもりですか?」です。
一般に、例外をまったくキャッチしないでください。
もちろん、他のすべてはその規則の例外です。ログに記録するために例外をキャッチすることは理にかなっています (ASP.NET のように環境がそれを行わない場合)。例外をキャッチして、コンテキストに関する詳細を提供する別の例外に置き換えることは理にかなっています。
public int GetConfiguredInteger(string name) {
string s = null;
try {
s = GetStringFromConfigFile(name);
}
catch (IOException ex) {
throw new Exception(String.Format(
"Error in configuration file foo.config when processing {0}", name),
ex);
}
return int.Parse(s);
}
呼び出し元は、IOException が構成ファイルによって引き起こされたものであることを、あなたが伝えていなければ知ることができませんでした。また、ファイル I/O に関連しないすべての例外を無視したことにも注意してください。特に、int.Parse が try/catch ブロック内にさえないことに注意してください。
このような例外は他にも少数ありますが、例外をキャッチする基本的な考え方は、そうしないと事態が悪化する場合を除き、実行しないことです。
resharper は例外に関するヒントを提供してくれると思います。ただし、C# はチェック済み例外をサポートしていないため、例外を特定する方法があります。おそらく、NDepend のようなコード分析ツールがこれをサポートしています。
すべてが例外をスローする可能性があります。メソッドによってスローされる可能性のある例外のリストについては、MSDN を確認してください。
空でないすべてのメソッドは、何らかの形で例外をスローできます。個人的に生成した例外が気になる場合は、次のように、フレームワーク メソッドが XML ドキュメントを介して行うのと同じ方法で、Intellisense から例外を表示できます。
/// <summary>
/// I seem to have written a method to do a thing.
/// </summary>
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
/* ... */
}
どんなコードも潜在的に例外を引き起こす可能性があります。これを試して予測するのはあなたの仕事です!
fxcop やリファクタリングなどのツールなど、いくつかの一般的なエラーを見つけるのに役立つサードパーティ製ツールがいくつかあり、提案を行うことができます。
現在、潜在的な例外を見つけるのに役立ついくつかの作業が行われています。関数のテストを生成するのに役立つ PEX を調べてください: research.microsoft.com/en-us/projects/Pex/ (リンクは投稿時にダウンしているようです)
もう 1 つのエキサイティングな分野は、コード コントラクトです (.net 4 で提供/仕様番号として利用可能)。コード コントラクトを使用すると、満たす必要がある条件を指定するステートメントを記述できます。これらは、関数が呼び出される前後に行うことができ、不変条件を宣言することもできます。条件は、値 != null のような単純なものである場合があります。これらの条件は、コンパイル時および実行時に分析され、違反するコード パスがないかどうかがチェックされます。
メソッドによってスローされる可能性のある例外を表示するException Finderに追加されたリフレクターがあり ます。私はそれを使用したことはありませんが、.Net ユーザー グループ ミーティングでその例を見ました。
これを行うことができるツールがあります。試用版をダウンロードして、気に入るかどうかを確認できます。それほど必要ではないと思いますが、もしあなたが会社で働いていて、彼らがその費用を払ってくれるなら、調べてみた方がいいかもしれません。前に述べたように、発生する可能性のある例外が多すぎます。Expetion Hunterをチェックしてください
外側の catch ブロックの内側を壊して、例外が発生した実際のポイントまで掘り下げるのは、はるかにイライラします。
ほとんどの場合、予期せずに例外がスローされた場合、バグを見つけました。何もしない例外処理によって難読化されていなければ、バグを解決するのは簡単です。
編集: あなたの例は実際には良いものなので、そのようなツールが役立つとはまだ確信していません. 文字通りすべてのコード行がスローする可能性のある非常に多くの例外があり、「興味深い」ものを見つけるのに苦労するでしょう。
数人が言及した Exception Hunter は、これを支援する優れたツールです。<exception>
コードによってスローされた例外の文書化を強制できるように、XML-Doc コメントと結び付いているかどうかはわかりません。