Break on Exceptions Thrown only from Specific Modules in Visual Studio 2017
In Visual Studio 2015 we introduced the new Exception Settings window which provides you a quick way to configure the debugger to break when exceptions are thrown. As part of that window revamp, we heard that simply filtering by exception type is not always good enough, you need finer grained control over when the debugger breaks on thrown exceptions. So in Visual Studio 2017 we are introducing a new feature that allows you to control breaking on thrown exceptions beyond just type. You can add a Module Name condition to an exception so you will only break on exceptions thrown from modules you care about.
Recap – Break when Thrown
The reality is that you need to handle exceptions in your code so that your app gracefully degrades when unexpected conditions occur, but as a developer you still need to figure out why the app is hitting those unexpected conditions. So you want to debug the app at the point the exception is thrown instead of having to navigate through code to figure out what exception is being handled and where it is being handled. When debugging issues that involve handled exceptions, you can tell the debugger to break when the exception is thrown using the Exception Settings window. This allows you to stop under the debugger and inspect the exception before it is handled. You can do this for a specific exception type or an entire category of exceptions.
If you always debug a program with a category of exceptions set to break when thrown you will be able to catch exception-related issues as early as possible in the execution of the program, which helps to make sure that every exception is being handled in the right way.
However, sometimes there are too many exceptions being thrown to make this debugging technique valuable because you would have to press “Continue” on every exception before finding the code you’re interested in. These ‘ignorable’ exceptions are often encountered in code where the exceptions aren’t fatal. For example, your app attempts to read stored settings, and if it fails to read a stored setting it will simply fall back to its default behavior. These non-fatal exceptions can frequently occur in third party libraries, code that is not under active development, or even code owned by another team not relevant to your debugging task at hand. By introducing a Module Name condition on your thrown exceptions, you can now limit the number of unnecessary breaks you encounter while debugging.
In Visual Studio 2017 we support only one type of condition, the “Module Name” condition. For any module I can decide if I only want to break on exceptions thrown from that module (Module Name Equals) or if I want to ignore breaking on exceptions thrown from that module (Module Name Not Equals).
Let’s look at an example.
Example – Adding Module Name Condition
In this example, every time I start my application I use a Settings library (SettingsLibrary.dll) that loads the user’s settings based on registry key values. In the event that no settings have been applied yet (which happens frequently), I throw and handle the resulting Argument Exceptions (there are a lot of them). I am debugging with exceptions breaking when thrown and hitting these exceptions frequently.
I know my Settings library is doing its job and I don’t need to break on any exceptions that occur in that module.
Note: In the screenshot above you can see the new Exception Helper. Read more about using the new Exception Helper here. I could choose to check the box in the Exception Settings section of the Exception Helper and then for only System.ArgumentExceptions, I wouldn’t break in SettingsLibrary.dll. In this example instead I want to apply that condition to the whole category of .NET Exceptions.
So I add a Module Name condition in the Exception Settings window so I won’t break on any exceptions thrown from my Settings library (which is its own module).
- Open Debug->Windows->Exception Settings
- Click on an exception type or category
- Right click on that exception and choose “Edit Conditions”
- Or click the blue edit pencil in the toolbar
From the Edit Conditions dialog:
- Set the condition using “Equals” or “Not Equals” (e.g. “Module Name Not Equals *Settings*”)
- Use asterisks (*) as wildcards before or after a keyword to match with module names containing that keyword
- Click OK to set the condition
When I press OK, my condition is set and I can see it in the Exception Settings window under the Conditions column.
When I set a condition on a category it applies that condition to all of the children in that category every time I edit it and press OK. Now my condition is set and I won’t break on exceptions thrown from my Settings library while debugging.
Some additional capabilities of Module Name conditions include:
- Setting a condition on a specific exception type (e.g. System.ArgumentException)
- Using the exact name of the specified module (e.g. “SettingsLibrary.dll”)
- Adding multiple “Module Name Not Equals” conditions using the “Add Condition…” link
Wrap Up
We encourage you to download Visual Studio 2017 today and try out this new functionality, and send feedback about the experience. Right now we only support the Module Name condition, but we want feedback on other types of granularity you would like to apply to breaking on thrown exceptions that we could support in the future. We hope you find this functionality useful and please let us know if you have any questions in the comments section below, using the Send Feedback feature in Visual Studio, or through Twitter.
Sign up to help us improve the Visual Studio Debugger: aka.ms/debuggerfb
Light
Dark
0 comments