25

リフレクションを使用してオブジェクトからプロパティ値を取得するコードがあります。場合によっては、null 参照があるなどの理由で、プロパティが例外をスローすることがあります。

object result;
try
{
    result = propertyInfo.GetValue(target, null);

}
catch (TargetInvocationException ex)
{
    result = ex.InnerException.Message;
}
catch (Exception ex)
{
    result = ex.Message;
}

最終的にコードは正しく動作しますが、デバッガーで実行している場合:

プロパティが例外をスローすると、例外がキャッチされなかったかのように IDE がデバッガーにドロップします。実行をクリックすると、プログラムが流れ、例外が TargetInvocationException として出力され、InnerException プロパティに実際の例外が含まれます。

どうすればこれを防ぐことができますか?

4

2 に答える 2

30

これは「設計による」ようです。メニューツール→オプション→デバッグ→一般→マイ コードのみを有効にする が有効になっている可能性があります。

How to: Break on User-Unhandled Exceptionsは次のように述べています。

[ Debug ] → [ Exceptions ] ダイアログには、[Enable Just My Code] がオンの場合、追加の列 (例外がユーザーによって処理されない場合は中断) が表示されます。

基本的にこれは、例外がコードの境界を離れるとき (この場合、.NET フレームワーク リフレクション コードに落ちるとき) はいつでも、例外がユーザー コードを離れたと見なされるため、Visual Studio が中断することを意味します。スタックの後半でユーザー コードに戻るかどうかはわかりません。

したがって、2 つの回避策があります:メニューの [ツール] → [オプション] → [デバッグ] → [全般] で[マイ コードのみ] を無効にするか、[デバッグ] → [例外] ダイアログの [ユーザーによって処理されない .NET Framework の例外] のチェック ボックスをオフにします。

于 2010-05-14T01:02:26.660 に答える
4

編集:私はこれを自分で試してみましたが、反射の扱いが少し異なるようです。デバッガーに関する限り、リフレクション呼び出しを新しいレベルの「処理」を開始するものと考えてください。例外が変換されて として再スローされる前に、その例外をキャッチするものは何もないTargetInvocationExceptionため、侵入します。わかりません。それを抑制する方法があれば-しかし、それは非常に頻繁に起こりますか? 例外が発生する多くの操作を定期的に実行している場合は、設計を再検討することをお勧めします。

元の答え

Debug / Exceptions... に移動し、設定を確認します。TargetInvocationException(または階層の上位にあるもの) で「Thrown」チェックボックスがオンになっている場合、この動作が見られます。

于 2010-04-17T15:36:03.783 に答える