未処理の例外はどのアプリケーションにとっても致命傷である。ユーザの相互作用なしで実行されるアプリケーションにとっては特にそうといえよう。理想的に は、この問題の潜在性をコンパイラーが見抜き、デベロッパに警告すればよいのだが、現在の.NETコンパイラーは、どの例外を投げるのかさえ決定すること ができない。
これに対処するために、Red GateはException Hunter(source)をリリースした。このツールは、メソッドを分析して、それが投げることができる例外を決定する。レポートはインタラクティブに表示されたり、CruiseControlのような自動化ビルドプロセスにつながれている。
ほとんどのRed Gateソフトウェアのように、Exception Hunterはシンプルかつ分かりやすいインターフェイスである。しかし残念なことに、簡潔とはつねに使いやすいことと解釈されるとは限らない。ツールが レポートを生成することができるが、それはコマンド行からのみの話である。この単純なタスクは、GUIではまったくない。
さらにイライラすることは、メソッドリストが、例外を実際に投げるメソッドはどれなのかを示さないことである。メソッドによっては太字で表示されるが、そ れはメソッドがベースクラスから継承されていないことを意味するだけである。ユーザは、各メソッドを別々に教え込む必要がある。
1つを除いて、これらすべては見落とされている可能性がある。その1つとは、false positiveの数がばかばかしいほど多いということである。この単純なVBアプリケーションを検討してみる。
この数行が投げることができる例外には、以下のものが含まれる。
- ArgumentException 6
- ArgumentNullException 4, 6
- ArgumentOutOfRangeException 4, 5, 6
- FormatException 4, 6
- IndexOutOfRangeException 6
- InvalidCastException 6
- InvalidOperationException 6
- ObjectDisposedException 6
- IO.PathTooLongException 6
- NotSupportedException 6
- NullReferenceException 6
- OutOfMemoryException 4, 5, 6
重要なアプリケーションが生成するノイズを想像することしかできない。
効果的な例外分析は業界にとって素晴らしい恵みとなるが、Red GateのException Hunterはまだそこに到達していないことを実証している。そして、これが解決可能な問題どうか、疑問を抱く必要がある。