You know, if it weren't for exceptions our jobs would be so much easier. Of course, if it weren't for our jobs exceptions wouldn't exist either. But they exist. And we cringe.

Sometimes they are just so very hard to track down –elusive little buggers that they are. You might try debugging your code in Visual Studio, hoping you get a nice little popup to explain an exception has occurred. What you may not know, however, is that Visual Studio only breaks on unhandled exceptions by default. If there is a try-catch block around the exception, the debugger doesn't care and will continue execution until it hits a breakpoint or an unhandled exception.

There are times however, when breaking on any exception can be helpful, handled or not. For instance, you may be getting an exception which has bubbled up from another exception, and the stack trace isn't enough to figure out exactly where it originated from.

To do this, you will first need to add the Exceptions… menu item to the Debug menu. You can actually add it anywhere you like, but I prefer the Debug menu. First, right-click on the menu bar and choose Customize… at the bottom of the context menu. Choose the Commands tab, and Debug from Categories. Now in the Commands listbox, you can select the Exceptions… item, and drag it into your Debug menu.

Here's how it looks for me:

Now that the menu item is all set up, click to Debug | Exceptions. The following window will appear:

All that remains now is to select the Thrown checkbox for Common Language Runtime Exceptions, and Visual Studio will break on each and every CLR exception as they happen. Keep in mind that this is a global Visual Studio setting, so you will need to manually change it, or change it back, for each project or debugging session.

One last note: if you want to get really specific about which exceptions Visual Studio breaks on, you can expand the group, and get a list of assemblies and types, which can further be expanded into specific exceptions: