Say I have the following code:
async void buttonClick(object sender, RoutedEventArgs e)
{
await nested1();
}
async Task nested1()
{
await nested2();
}
async Task nested2()
{
await nested3();
}
async Task nested3()
{
await Task.Delay(1000);
throw new Exception("Die"); // <-- I want Visual Studio to break on this line
}
How can I make Visual Studio break on the indicated line only when the exception is unhandled?
Normally when the exception is thrown, Visual Studio will break here in App.g.i.cs:
If I then enable "Just my code" in the debugger options, it will break here instead:
Getting close. If I then check System.Exception
under the "Thrown" column in the Exceptions window (Ctrl+Alt+E), it will break exactly where I want:
but now Visual Studio will break on all thrown exceptions, not just unhandled ones. Is there any way to get Visual Studio to break at the most logical line of code only for unhandled exceptions, just like it would in regular non-async code? If this behavior is not possible, then:
- Why is it not possible?
- How can I identify the line of code that has thrown the exception, whether that be a
throw
statement of my own code, or a framework method call that has thrown an exception?
I've used 3 nested functions here in this example to emphasize that my code may be complex with many branches and nested method calls, and identifying the problematic line of code is difficult if Visual Studio doesn't break on the innermost line of code.
It's not possible.
Because it's not done yet.
async
is still getting better tooling support with every release, and I do expect this behavior to be added sooner or later.Visual Studio 2013 does have the ability to view asynchronous causality stacks in the debugger. If you want similar behavior at runtime, then you can use my async diagnostics package.
I think I may have discovered the answer to my question.
First, I uncheck
System.Exception
under the "Thrown" column in the exceptions window (Ctrl+Alt+E). I do this because I don't want Visual Studio to break on all exceptions, only unhandled ones.Second, I keep "Just my code" enabled in the debugger options.
Now, when the debugger breaks, it will break here:
as per the screenshot in my question. But if I inspect the call stack:
I can actually see where the exception originated from (in
nested3()
, line 46). If I click this entry in the call stack window, Visual Studio will jump to the correct line, and the "Locals" window will even show me the values of local variables in that frame. Cool! I think this is what I wanted.