Maintaining and debugging code can be a difficult task even at the best of times, I have witnessed otherwise well designed code swallow exceptions so thoroughly that there is hardly any trace of that they ever occurred. I have seen master developers brought to tears attempting to configure meaningful breakpoints for multi-threaded applications. So I am probably more excited than I should be for the improvements to Exceptions Settings and Breakpoints.

Exceptions Settings

In previous version of Visual Studio Exception Settings used to be a modal window where you could basically decide what general category of exception you wanted your application to respond to while debugging. So if your apps were happily catching all your exceptions gracefully, but you need to see them any way, you could always ask Visual Studio to Break on Exceptions.

Now with VS 2015 Exceptions Setting is configured in a non-modal window and with a better interface for configuring your debugging environment, you can quickly change your approach to debugging very specific problems, the new window looks like this (new location under Debug->Windows->Exception Settings [Ctrl-Alt-E]):

ExceptionSettingsWindow

It should look familiar especially categories like Common Language Runtime Exceptions, but WebKit and Python are worthy additions for Visual Studio and its expanding developer base. The cool this is that you you can efficiently filter this list to change the behavior of any kind of exception you are interested in, or you can indeed modify all of them. 

ExceptionSettingsFilter

If you have developed your own custom exceptions you can add those to the list here also.

Break Point Improvements

In VS2015 hovering over break points and clicking on, what looks like, the gears popups a peak window with the Conditions and Actions options.

ConditionalBreakPoint

Options for Conditions are as follows:

  • Hit Count - If you have errors in a for each, you can easily stop and inspect based on the number of times you hit the exception.
  • Filter - Allows you select parameters of a particular thread, things like Thread Id and Process Name, for example.
  • Conditional Expression - This is my favorite, you can put any expression that evaluates to a Boolean.

With the Actions option you can elect to send results to the Output window.

ConditionalExpressionBreakPoint

To be clear these options have existed in prior versions for a long time but were for a variety of reasons a little awkward to manipulate during active debugging. I did not know how much the accessibility of these features needed to be revamped until they were.

Related Posts: