20

私は非常に大規模なレガシー コードベースに取り組んでいます。常に最適に維持されているとは限らないため、制御フローから、またはその他のさまざまな理由で例外が使用されることがあります。また、ほとんど避けられない場合もあります。たとえば、ファイルをイメージとして渡し、例外がスローされないかどうかを確認する以外に、ファイルが有効な .ico イメージであるかどうかを確認するにはどうすればよいでしょうか?

私はできる限りこの種のものをリファクタリングしますが、ほとんどの場合、リファクタリングするにはコストがかかりすぎてほとんど利益が得られません。これらの偽の例外は、デバッグ時に非常に煩わしくなります。プログラムがクラッシュしないようにすべての例外をキャッチし、ほとんどの例外をキャッチして、もう少しユーザーフレンドリーなものを表示します。そのため、デバッグ中にコードの一部が をスローするApplicationExceptionと、最終的に実際のバグに到達する前に、そのタイプの例外が 50 回スローされる可能性があります。ほとんどの場合、これらの偽の例外は、コードの 1 つの部分 (多くの場合 1 行) に集中しています。その行からスローされた例外を無視するようにVisual Studioを取得する方法はありますが、実際の問題である例外で停止しますか? または、この種のデバッグのフラストレーションを防ぐために他にできることはありますか?

私の問題を説明するために、次のようなものを想像してください。

for(int i=0; i<foo; i++)
{
  try
  {
    FooBar(i); //this function throws NullReferenceException sometimes
  }catch {} //ignore it because we don't care if it failed
}
....
var tmp=Bar as FooType; //this cast fails so tmp is null
tmp.Meh(); //throws exception here. This is a bug, we should've checked for null

NullReference がどこにあるかを把握したい場合は、基本的にFooBar呼び出しを過ぎるまで F5 を押し続けます。これはせいぜい面倒で、エラーが発生しやすい

4

3 に答える 3

1

中断が発生する例外の種類を調整できます。メニューのデバッグ - >例外を 参照してください http://msdn.microsoft.com/en-us/library/d14azbfh(v=vs.80).aspx

于 2013-01-08T16:34:06.900 に答える
1

私が見たところ、デバッグの複数の手法を組み合わせて、リファクタリング プロセスを改善できます。

可能であれば、レガシー コード (の一部) を別のアセンブリに配置できます。それらを最適化してコンパイルし、「Just my Code」デバッグを有効にします。

小さいブロック (メソッド) の場合は、DebuggerStepThrough属性を使用できるため、デバッガーはそこで中断しません。あなたの例では、FooBar メソッドを呼び出すループを実行するメソッドを作成し、新しく作成したメソッドに [DebuggerStepThrough] を配置できます。または、FooBar をリファクタリングして例外を処理し、[DebuggerStepThrough] を配置することもできます。

于 2013-01-09T12:39:27.237 に答える
0

C++/C# コードのデバッグを容易にするVisual Studio の拡張機能 IntelliDebuggerを開発しています。例外のある作業を含みます。IntelliDebugger は、ソリューションに含まれていないモジュールからスローされた例外をフィルター処理できます (この機能は、「ソリューションからのみ例外をブレークする」と呼ばれます)。おそらく、この機能はあなたに役立つでしょう。

将来のバージョンでは、例外を処理するためのより優れたフィルターやその他の機能を追加する予定です。機能のリクエストやバグ レポートがある場合は、私に連絡してください。これにより、製品をお客様にとって特に便利なものにすることができます。

于 2013-01-09T12:27:33.497 に答える