The screenshot above is taken from a simple program that’s using the ‘await’ pattern with break on thrown exceptions turned off.
This is especially helpful in the case of async exceptions, which are caught and then re-thrown by framework code. This helps you get to the root cause in your code of any rethrown exceptions. Ever had a bug in an async method that caused an exception? Been frustrated that the debugger doesn’t show you where that exception happened? Or been frustrated when looking at an exception that has an inner exception, but the debugger doesn’t easily show you where that exception was from? Starting from the Visual Studio 2019 16.5 release, the exception helper now contains the original call stack for a rethrown exception.
