抑制第一次机会异常
是否可以在 Visual Studio(C# 调试器)中抑制特定代码行的第一次机会抑制?
我想在调试器中使用首次机会异常,但在获得有趣的代码之前,我需要经历大约 50 个首次机会异常。
目前,我关闭第一次机会异常,然后手动将其打开,但这既麻烦又浪费时间。
Is it possible to suppress first chance supressions in Visual Studio (C# debugger) for specific lines of code?
I want to use first chance exceptions in the debugger, but there are about 50 first chance exceptions I need to go through every debug session before I get to the interesting code.
Currently, I turn off first chance exceptions and then manually turn them on, but that's a hassle and a time sink.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
DebuggerNonUserCodeAttribute 类
从 .NET 2.0 开始,如果使用 [DebuggerNonUserCode] 属性,调试器将跳过其中的第一次机会异常。
引用自 MSDN 链接(强调的是我的):
除了调试之外,没有与此属性关联的运行时行为。
但是,如果您只有一种方法,其中某些行打算包含在 Visual Studio 的第一次机会异常处理机制中,而其他行则被排除在外,那么在这种粒度级别上可能没有解决方案。 您始终可以将一个大型方法重构为多个方法,并在选定的方法上使用该属性。
其他信息...
本文
本文显示了可能有用的相关 VS 项目选项。< br>
DebuggerNonUserCodeAttribute Class
As of .NET 2.0, if you mark an method with the [DebuggerNonUserCode] attribute, the debugger will skip first chance exceptions in it.
Quote from MSDN link (emphasis added is mine):
There is no runtime behaviour apart from debugging, associated with this attribute.
However if you have just one method with certain lines intended for inclusion in Visual Studio's first chance exception handling mechanism, and other lines to be excluded, there's likely not a solution at this level of granularity. You can always refactor a large method into multiple methods and use the attribute on select ones.
Additional Info...
Example usage from this article
The article shows related VS project options that might be useful.
发生这种情况是因为您错误使用了异常。 在到达“有趣的代码”之前就获得 50 并不是一个好兆头。 Visual Studio 中无法在某些代码中跳过它们,因为它并不是为了鼓励您所做的事情而设计的。
也就是说,我要做的就是关闭调试器中捕获第一次机会异常的功能,显式尝试/捕获您想要捕获的异常,然后放入调试器。当您捕获它时,请 Break() 。
This is happening because you are mis-using exceptions. Getting 50 before you get to the "interesting code" is not a good sign. There is no way in Visual Studio to skip them in some code, because it's not designed to encourage what you are doing.
That said, what I'd do would be to turn off catching first-chance exceptions in the debugger, explicitly
try/catch
the exception you do want to catch, and put in aDebugger.Break()
when you've caught it.