Customizing Exception Handling in the VS Debugger

In the last two weeks I’ve gotten many questions about how to automate and program the exception handling the Visual Studio debugger so I thought I’d show how to some cool macros I’ve created to make it easy. If you’re interested in more about making the most of the debugger you can always come to our Devscovery conference in New York City starting on April 14th. (Bethany, Wintellect’s marketing maestro, is going to love me for working in the advertisement there!).

All the questions I got about the debugger exception handling fell into two buckets. The first was that teams have custom exceptions that they want to add to the Exceptions dialog and don’t want to have to add those manually every time the move to a new machine. Since the Exception settings are stored in the .SUO file next to the solution, you also lose those exceptions if you delete the .SUO file. The second question was about programmatically setting just a handful of exceptions to stop when thrown. What was interesting about the second question is that the people asking had the neat idea of having their tests running under the Visual Studio debugger and configured to ignore all exceptions but a handful. That way they’d have those tough error conditions already in the debugger in order to make their debugging easier. I thought that was a very interesting idea.

As with most things in life, there’s some good news and bad news about programmatically manipulating exceptions through the Visual Studio automation model. The good news is that the automation model has everything you need. The bad news is that certain operations, like setting all exceptions to stop when thrown, if done with a macro as so abysmally slow that it’s essentially unusable. I suspect the performance would be better if I wrote an add-in. I’m hoping the VS 2010 will improve the performance of macros so more people will consider writing quick extensions to the IDE.

Let me start by showing you a simple macro from Jim Griesmer that sets a CLR exception to stop when thrown:

The macro itself if relatively straightforward. Once you have the Debugger3 interface, you can get the exceptions under a category by name. As you probably guessed the names of the exception groups maps to exactly what you see in the Exceptions dialog in Visual Studio.

Note that my Exception dialog probably looks different than yours because I turned off Just My Code in the Visual Studio Options dialog (Options, Debugging, General). I highly recommend you do as well because having Just My Code turned on turns off very valuable features such as debugging optimized builds and the awesome .NET Reference Source Code debugging.

The real work in the macro is all in the ExceptionsGroup interface as it has the methods on it to set, create, and remove individual exceptions. To get an individual exception, you access the ExceptionsGroup Items collection by exception name to get the ExceptionSetting.

At the bottom of this blog entry, I included the macro source code for a set of macros that wrap up adding, removing, and configuring CLR exceptions easy with full error handling and reporting. For those of you doing native development, you’ll get the idea what you need to do. The one difference with Win32 Exceptions verses the other categories of exceptions is that you’ll need to specify the exception codes to those exceptions.

In the code I wanted to include macros that would let me set or clear stopping when exceptions were thrown. The problem was that the macro literally took more than 15 minutes to enumerate and set each exception setting. It’s faster to manually bring up the Exceptions dialog and click the check box next to the category. I’ll keep looking to see if I can find a faster way to enable and disable stopping when thrown.

Those of you using my Debugger Settings add in I’m working on adding support for exception settings to it. Keep reading this space for updates. I’m worried about the performance of saving and restoring the exception settings given the horrible performance I’m seeing from the macro so it may turn out I won’t add it.

The team that was running their tests under the debugger and wanted to automate setting various exceptions also was looking for a way to programmatically execute a macro in Visual Studio. They wanted to be able to configure their special exceptions as well as automatically attach or start their application. Fortunately, that’s easy to do with the /command command line option to DEVENV.EXE. That will start the IDE and execute a Visual Studio command or macro.

As always, let me know if you have any questions or have an idea you’d like to see explored.

Related posts:

No related posts.

Anonymous

I know that this is a super-old post, but I thought I would post a comment/question anyhow.I have been trying turn on/off exception-catching programmatically and so thanks for posting information on it. Like you, I noticed that th performance is pretty poor — it takes a moment to turn on/off one kind of exception, and so if you try to do something like I did:Dim exceptionGroup As ExceptionSettings = debugger.ExceptionGroups.Item(“Common Language Runtime Exceptions”)For Each item As ExceptionSetting In exceptionGroup exceptionGroup.SetBreakWhenThrown(True, item)NextThen it takes an eternity.Really I don’t care to turn on/off specific ones, I’m happy to just turn on/off the entire CLR Exception group, which is what I normally do when I am doing it manually through the dialog.I have not come across any way to programmatically change the settings of an entire ExceptionSettings group at once, besides iterating them the slow way that I posted above. Are you aware of any shortcut for setting the state of an ExceptionSettings group?

http://www.gagmaniacs.com/ Anonymous

I can’t get over how sensational your writing type is, you have to publish lots much more.