スローされてキャッチされたときに、その例外でデバッガーを停止しないでください。

91

ツール/例外では、例外がスローされたときにデバッガーが停止するオプションを設定しました。捕まるかどうか。

そのルールの例外を除外するにはどうすればよいですか？私のコードのどこかに、プログラムロジックの一部であるキャッチされた例外があります。そのため、例外が発生するたびにデバッガーを停止させたくないのは明らかです。

例：344行目のnull参照の例外（キャッチされる）を無視します。他のすべての例外で停止したい

— MichaelD
ソース

6

この例外がプログラミングロジックの一部である場合（本当にこの方法で実装する必要があるかどうかを考えてください）-例外は、少なくとも独自に作成した派生例外である必要があります。このようにして、ブライアンの解を適用できます。

— tanascius

ここで問題がある：stackoverflow.com/questions/1957907/...

— MichaelD

2

@tanascius-+1私はほとんどの場合同意する例外は論理的な決定を行う最善の方法ではありません。ただし、例外の処理を逆シリアル化する場合など、場合によっては避けられないことがあるため、throw> catch> handleが唯一の適切なオプションです。

— jpierson

2

@安藤さん、ごめんなさい。複数のタブを一度にモデレートすることは効率的ですが、常に正確であるとは限りません。

2

@tanascius：応答で独自の例外をスローする前に、既知のフレームワーク例外をキャッチする必要がある場合があります。あなたの提案は常に可能であるとは限りません。

— Dan Puzey、2012

40

正しく思い出せばDebuggerStepThrough、例外を発生させたくないコードを含むメソッドの属性を使用できます。メソッドで厄介な例外を発生させるコードを分離して、属性で装飾できると思います。

— クリス・チョウ
ソース

31

マリンジャーの答えと私の経験から、この答えは正しくないようです。このDebuggerStepThrough属性は、初回例外のデバッガの動作には影響しません。

— Michael

5

@ティム、私はテストしましたが、止まりません。私の答えをチェックアウト：stackoverflow.com/questions/1420390/3455100#3455100

— Shimmy Weitzhandler 2010

1

+1は、純粋な.NET 4.0のVS2010および処理されない例外のSilverlight 4コードで機能します。

— Mike Post

6

重要な注意：これはasync-awaitタイプのメソッドでは機能しません。詳細はこちら

— i3arnon 2014年

8

MSDNによれば、このDebuggerStepThrough属性はCLRにとって意味がありません。デバッガによって解釈されます。さまざまな状況下では確実に機能しないようで、確実に機能しDebuggerHiddenます。stackoverflow.com

— Eric J.

64

DebuggerHidden あなたの友だちです！

共通言語ランタイムは、この属性にセマンティクスを付加しません。ソースコードデバッガーで使用するために提供されています。たとえば、Visual Studio 2005デバッガーは、この属性でマークされたメソッドで停止せず、メソッドにブレークポイントを設定できません。Visual Studio 2005デバッガーによって認識される他のデバッガー属性は、DebuggerNonUserCodeAttributeとDebuggerStepThroughAttributeです。

VS2010でテストされ、優れた動作をします。

ながらDebuggerStepThroughも、いくつかの特定のデバッガバージョンのために働くようだ、DebuggerHidden両方の答えへのコメントに基づいて状況の広い範囲のために動作するようです。

現在、どちらのオプションも、イテレーターブロックメソッドやasync / awaitメソッドでは機能しません。これは、Visual Studioの今後のアップデートで修正される可能性があります。

— シミー・ワイツハンドラー
ソース

VS2008に取り組んでいます。キャッチブロックを含むメソッド全体に適用する必要があります。そうしないと、どこか別の場所で中断してしまいます

— Mark Heath

1

その属性をメソッドに追加すると、デバッガーは代わりにそのメソッドの呼び出しで停止しました。何か不足していますか？

— Doogal

1

それはそうあるべきである方法です。それを回避するには、例外を処理する必要があります...または、代わりに呼び出し元メソッドもマークDebuggerHiddenします...

— Shimmy Weitzhandler

1

DebuggerStepThrough属性は、例外によるブレークを回避するのに十分であることに注意してください。DebuggerHiddenは、DebuggerNonUserCodeとDebuggerStepThrough属性の両方の組み合わせのように機能します。

— jpierson

1

悲しいことに、問題のメソッドがイテレータメソッドの場合、これは機能しません：/

— Roman Starkov

14

DebuggerStepThroughは、try / catchがあるメソッドでデバッガーが壊れないようにするために使用されるものです。

ただし、Visual Studioのデバッグオプションの一般設定（[ツール] / [オプション]、[ノード] [デバッグ] / [一般]）で[コードのみを有効にする（管理のみ）]オプションをオフにしなかった場合にのみ機能します。

その属性の詳細については、http：//abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/をご覧ください。

DebuggerHiddenは、例外がスローされたメソッドをデバッガが表示しないようにするだけです。代わりに、その属性でマークされていないスタック上の最初のメソッドを表示します...

— ヴァレリー・レトロワ
ソース

1

これはVS 2015ではデフォルトで機能しなくなったことに注意してください。それを有効にする方法については、VSブログを参照してください

— bhh

悲しいことにVS 2015この問題を回避するには、VS 2019のためではない仕事をして

— ジョナサン・アレン

13

他の回答で指定された属性（およびDebuggerNonUserCode属性などの他のもの）は、Visual Studio 2015ではデフォルトで同じように機能しなくなりました。以前のバージョンのVSとは異なり、デバッガーはこれらの属性を持つメソッドマーケットの例外で中断します。動作を変更したパフォーマンス強化をオフにするには、レジストリ設定を変更する必要があります。

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

詳細については、ビジュアルスタジオのブログをご覧ください。

（これはおそらくトップの回答に対するコメントになるはずですが、十分な担当者がいません）

— うーん
ソース

3

コードの特定の場所でスローされた例外を特定することはできません。ただし、特定のタイプの例外を無効にすることができます。

独自のコードが問題の例外をスローする場合、私はそれをカスタム例外にして、適切なものから派生させ、この派生型のデバッグブレークを無効にします。

NullReferenceExceptionとしてシステム例外を無効にすると、システム全体に影響しますが、これはもちろん開発中には望ましくありません。

例外には2種類のブレーク動作があります。

スロー：選択した場合、このタイプの例外がスローされるとすぐにブレークします
ユーザー未処理：選択した場合、このタイプの例外がtry / catchで処理されない場合にのみ中断します。

NullReferenceExceptionの 'Thrown'のチェックを削除すると、システムがコード内の問題のある行を通過するたびにブレークしないという利点が得られますが、未処理のNullReference期待が他の部分で発生している場合でもブレークすることができます。システム。

— ラースウデンガード
ソース

3

DebuggerStepThrough属性をVisual Studio 2010のメソッドに追加すると、デバッガーがメソッドによってスローされた未処理の例外を停止できなくなります。

— Tim Murphy、

私はテストしましたが、それは妨げません。それはまだ止まる

— Shimmy Weitzhandler 2010

1

@シミー-私のために働く！DebuggerStepThroughがスローされた時点から、コールスタック内で例外を表示したい時点まで、各メソッドにDebuggerStepThroughを適用していることを確認してください。例外をキャッチして、すべてのメソッドがDebuggerStepThroughで装飾されている呼び出し階層内で処理すると、その例外でVSブレークが発生することはありません。

— jpierson