抑制第一次机会异常

发布于 2024-07-23 07:33:27 字数 154 浏览 3 评论 0原文

是否可以在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

冷默言语 2024-07-30 07:33:27

DebuggerNonUserCodeAttribute 类

从 .NET 2.0 开始,如果使用 [DebuggerNonUserCode] 属性,调试器将跳过其中的第一次机会异常。

引用自 MSDN 链接(强调的是我的):

成员
不属于代码的一部分
由用户专门创建可以
使调试体验变得复杂。

该属性抑制显示
这些辅助类型和成员
调试器窗口并自动
逐步通过,而不是进入,
设计者提供了代码。


除了调试之外,没有与此属性关联的运行时行为。

但是,如果您只有一种方法,其中某些行打算包含在 Visual Studio 的第一次机会异常处理机制中,而其他行则被排除在外,那么在这种粒度级别上可能没有解决方案。 您始终可以将一个大型方法重构为多个方法,并在选定的方法上使用该属性。


其他信息...

本文

using System.Diagnostics;
using XL = Microsoft.Office.Interop.Excel;

public static class WorkbookExtensions
{
    [DebuggerNonUserCode]
    public static bool TryGetWorksheet(this XL.Workbook wb, string worksheetName, out XL.Worksheet retrievedWorksheet)
    {
        bool exists = false;
        retrievedWorksheet = null;

        try
        {
            retrievedWorksheet = GetWorksheet(wb, worksheetName);
            exists = retrievedWorksheet != null;
        }
        catch(COMException)
        {
            exists = false;
        }

        return exists;
    }

    [DebuggerNonUserCode]
    public static XL.Worksheet GetWorksheet(this XL.Workbook wb, string worksheetName)
    {
        return wb.Worksheets.get_Item(worksheetName) as XL.Worksheet;
    }
}

本文显示了可能有用的相关 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):

members
that are not part of the code
specifically created by the user can
complicate the debugging experience
.
This attribute suppresses the display
of these adjunct types and members in
the debugger window and automatically
steps through
, rather than into,
designer provided code.

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

using System.Diagnostics;
using XL = Microsoft.Office.Interop.Excel;

public static class WorkbookExtensions
{
    [DebuggerNonUserCode]
    public static bool TryGetWorksheet(this XL.Workbook wb, string worksheetName, out XL.Worksheet retrievedWorksheet)
    {
        bool exists = false;
        retrievedWorksheet = null;

        try
        {
            retrievedWorksheet = GetWorksheet(wb, worksheetName);
            exists = retrievedWorksheet != null;
        }
        catch(COMException)
        {
            exists = false;
        }

        return exists;
    }

    [DebuggerNonUserCode]
    public static XL.Worksheet GetWorksheet(this XL.Workbook wb, string worksheetName)
    {
        return wb.Worksheets.get_Item(worksheetName) as XL.Worksheet;
    }
}

The article shows related VS project options that might be useful.
alt text

榕城若虚 2024-07-30 07:33:27

发生这种情况是因为您错误使用了异常。 在到达“有趣的代码”之前就获得 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 a Debugger.Break() when you've caught it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文