如何在Visual Studio中忽略异步方法的特定异常INSTANCE（中断抛出）

Question

If I set VS to break on thrown exceptions of a given type, and the debugger haltet at some piece of code, I look for a possibility to continue running (F5) and not break on each parent stack frame of the same exception.

In other words, I want a possibility to ignore the very instance of the exception for the rest of its stackframe (assuming it is caught somewhere above).

The only way I found is tedious (and error-prone if such exceptions are thrown often in some situation): Uncheck the "break when this type is thrown" checkbox, continue execution, immediately reactivate the exception in the Exception Settings pane.

---

Edit: clarifying to 1st answer

I forgot to mention (as I was not aware that this is relevant info) that I'm in async methods. I modified your example to async, like this:

    public static class Program
{
    public static void Main(string[] args)
    {
        try
        {
            Alpha();

        }
        catch (Exception e) // don't try this at home kids
        {
            // we should never get here in this example
            throw;
        }
    }


    private static async Task Alpha()
    {
        try
        {
            await Bravo(); //  *** 4 ***
        }
        catch (Exception e)
        {
            // debugger won't stop here because we didn't re-throw
        }
    }

    private static async Task Bravo()
    {
        try
        {
            await Tango(); //  *** 2 ***
        }
        catch (Exception)  // don't try this at home kids
        {
            throw;  // *** 3 *** debugger will stop here again because we are re-throwing
        }
    }

    private static async Task Tango()
    {
        var x = 1;
        var y = 0;
        var c = x / y; //  *** 1 ***

    }
}

And the debugger stops at all four marked spots in the numbered order. So it does not only stop at rethrows, but also at all awaits inbetween. And for deep call hierarchies, this is disturbing my debug-flow, so to speak.

So to summarize, I'd need a solution for async calls to not re-break at every await between the exception-causing stackframe and the one where the exception is eventually caught.

Possible?

Answer 1

---

With the new info that became apparent in the question, this answer may no longer be suitable. :)

---

If I set VS to break on thrown exceptions of a given type, and the debugger haltet at some piece of code, I look for a possibility to continue running (F5) and not break on each parent stack frame of the same exception....

The only way I found is tedious (and error-prone if such exceptions are thrown often in some situation): Uncheck the "break when this type is thrown" checkbox, continue execution, immediately reactivate the exception in the Exception Settings pane

Without seeing your code I can only assume you are re-throwing the same exception.

Consider the following code:

class Program
{
    static void Main(string[] args)
    {
        try
        {
            Alpha();

        }
        catch (Exception e) // don't try this at home kids
        {
            // we should never get here in this example
            throw;
        }

    }

    private static void Alpha()
    {
        try
        {
            Bravo();
        }
        catch (Exception e)
        {
            // debugger won't stop here because we didn't re-throw
        }
    }

    private static void Bravo()
    {
        try
        {
            Tango();
        }
        catch (Exception)  // don't try this at home kids
        {
            throw;  // debugger will stop here again because we are re-throwing
        }
    }

    private static void Tango()
    {
        var x = 1;
        var y = 0;
        var c = x / y;
    }
}

With the debugger set to break when System.DivideByZeroException is thrown, the debugger will:

1. stop first in Tango where it is attempts to divide by zero and the first exception is thrown
2. stop again in the catch() handler in Bravo where the exception is thrown again

But it will not stop in Alpha because I silently eat the exception.

The behaviour you are seeing is by design.