Suppress first chance exceptions

Question

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.

Murial

Answer 1

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.

Skaggs

Nice... I didn't know about this. – Murial

Thank you, so much. This makes debugging actuall unexpected exceptions a lot easier. – Propaganda

thanks, this finally solved my problem. Skeet/Gravell's "MiscUtil" relies on exceptions being thrown, and they are always caught as first-chance exceptions even though they're immediately handled. applying this attribute to some of their classes fixed this problem. – Monocle

You do realize that will still reach the 'FirstChanceExceptions' event handler. Your tip only tells the compiler not to break into the method you attributed. This doesn't solve the delima on what was asked here. "Identifies a type or member that is not part of the user code for an application." – Seng

This does not work for me in a netcoreapp3.1. The debugger still breaks on first-chance exception in methods annotated with the attribute. – Drislane

Answer 2

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.

Downandout

These are not my exceptions. My code is an add-in to an existing product. The existing product swallows exceptions from add-ins so I'd like to use 1st chance exceptions to ensure that none of my exceptions are getting swallowed, yet I don't want to slog through the existing exceptions that aren't being handled in their wrapper. – Murial

And I should restate, these are 1st chance exceptions, not 2nd chance exceptions. – Murial

Exceptions occur in complex programs in MANY situations, all out of the developers control. Automation, for example, raises exceptions when elements disappear while you are using them. Any time you deal with COM, or injecting into another process, exceptions are quite common. – Propaganda