Follow Us

Using the New Exception Helper in Visual Studio 2017

Dealing with exceptions is a common developer problem no matter your technology or level of expertise. It can be a frustrating experience figuring out why exceptions are causing problems in your code. When you are debugging an exception in Visual Studio, we want to lessen that frustration by providing you with relevant exception information to help you debug your issue faster. So in Visual Studio 2017 we are introducing the simplified, non-modal, new Exception Helper.

In previous versions of Visual Studio, when you break on an exception, you will see the Exception Assistant (when debugging managed code), or the Exception Dialog (when debugging Native code, or if you disabled the Exception Assistant).

Exception Assistant:

Exception Dialog:

We looked closely at both of these dialogs, listened to your feedback on User Voice and from Send-A-Smile, and decided they needed an overhaul.

Highlights of the New Exception Helper

Breaking on the Line of Code – No matter if you are managed or native debugging, when you break on an exception the debugger will stop you on the line of code where that exception happens. An exception error icon will appear to the right of that line of code and the non-modal, smaller, less distracting Exception helper will pop down from that icon and stay pinned to that code line.

Exception Information at a Glance – You will instantly be able to read the exception type and exception message in the Exception Helper, and whether the exception was thrown or unhandled.

Null Reference Analysis – Starting in VS 2017 , for both managed and native code, when you hit a NullReferenceException or an Access Violation, you will see null analysis information in the Exception Helper. If we cannot determine what is null we will not attempt to show any analysis. When we can detect what is null we will emphasize the culprit in bold text. For C++ Access Violations, this analysis will be present in Visual Studio 2015 as well.
Note: Null reference analysis in managed code requires .NET version 4.6.2. Null analysis is currently not supported for Universal Windows Platform (UWP) and any other .NET Core applications. It is only available while debugging code that does not have any Just-In-Time (JIT) code optimizations.

Configure your Exception Settings – When you break on Exception Thrown you can use the checkbox under Exception Settings in the Exception Helper to disable breaking on that exception type when thrown in the future. You can also specify that you do not want to break on this particular exception thrown in this particular module by checking the box by the module name under “Except when thrown from:” in the Exception Settings. You can apply conditions to your exceptions to only break when thrown from certain modules.

Inner Exceptions right away – No longer will you have to drill into the exception details to see if there is an inner exception. We show it to you right when you break with the ability to navigate back through multiple inner exceptions.

Move it where you need it – You can drag the Exception Helper from its pinned view to its floating view if it happens to cover up something you need to look at, or you want to view it while switching code files. You can also use the pin icon to float it, or snap it back to the line of code. If you close the Exception Helper, simply click on the exception error indicator to bring it back up.

Faster breaking for Unhandled Exceptions – When managed debugging, the debugger will no longer automatically unwind the Call Stack when you break on an unhandled exception. This means that you will break into your code faster because the debugger doesn’t need to walk the Call Stack before breaking.

Non-Modal – When native debugging, you will no longer need to dismiss an exception dialog to inspect your code. The new Exception Helper is available right inline next to your code.

If you need to turn off the Exception Helper go to Debug/Options, scroll down the list and un-check the box for “Use the Exception Helper”. Then use the report a problem feature of Visual Studio to let us know why the Exception Helper wasn’t working for you.

Wrap Up

Download Visual Studio 2017 today, use the new Exception Helper, and send us feedback about the experience. We hope you find this it useful and let us know if you have any questions in the comments section below, using the Send Feedback feature in Visual Studio, or via Twitter.

@Dave Shaw, we are excited to bring this information front and center. How many inner exceptions do you normally encounter? Which one would you like to see first, the inner-most exception or the top level inner exception?

@Kaycee, I don’t think that many, but when I get one I often want to see what it is, rarely do I not need to look at it.

Would I prefer the Outer or Inner first, probably the outer, but I’m just that kind of person I guess.

I’m only thinking about 2 levels deep here, most of my code is never more than that, but there are some cases where legacy .NET code has a long chain of nested exceptions and it would be nice to drive down.

Improving the exception dialog is nice. What would be really helpful would be to allow the ability to ignore certain exceptions from being handled. Not certain types of exceptions, we can already do that, but certain exceptions that always occur, but occurs in somebody else’s code, which means you can’t fix the problem.

Currently the only options we have is to either disable an exception type completely, which means you may potentially miss out on exceptions you were interested in or enable just my code which will hide the exceptions, unless you happen to have the debug information for the code containing the exception, in which case you are back at having to disable the type of exception.

What would be especially helpful, especially in longer/complex statements, is if when you get a null reference exception, it highlighted or told you in some manner which thing was null. For more complex expressions, that can take a little digging sometimes.

The no-modal exception details is amazing, but I do wonder why it was ever shown as a modal in the first place and why it stayed that way for so long. I’m sure theres a valid reason, but it’s such a pain for me to have switch back and forth between closing the exception details when I want to dig around my code, and having to find back the tab that contains the exception and reopening the exception details

Is this feature lost in VS2017 / C++ ? It does NOT show the exception message, neither when I throw char literals nor when I throw std::exceptions. To enable break on throw, I have to outcomment my catch clause.