You write excellent code with
catch statements, now how do you get the application to stop when you have an error when debugging?
In previous versions of Visual Studio for Visual Basic, a simple preference setting existed that told the debugger to stop on all errors, unhandled errors, or not to stop. It was easy to adjust and get to. How times changed, and I couldn't find the equivalent for a while, though I didn't look hard. Then came the big moment, I had to debug somebody else's code. I knew Microsoft had to put the setting somewhere, just where did it go?
How do we make debug mode stop on errors?
Here It Is!!!!
While looking at code in Visual Studio 2003, click on the Debug menu. Click on Exceptions. You can also enter Ctrl-Alt-E to bring up the screen, if you haven't associated it to something else.
Microsoft took our old Visual Studio VB preference and turned it into something useful. Microsoft likes the idea of Exceptions falling under a category of exceptions. For the highlighted category, you have options when an exception occurs, just like the old days. Most of the time in .NET development, we're worried about Common Language Runtime Exceptions. Let's see what has been categorized under the Common Language Runtime Exceptions category.
As you can see, many exceptions exist in the .NET framework. With each of them, we can use the options provided to break in debug mode. This is a heck of a lot easier than setting debug statements all over the place, now isn't it?
Testing It Out:
I put together a simple project that has a custom exception. Each button makes different kinds of calls.
- Exception button has a simple code that throws a base
Exception and catches it.
- Not Implemented button throws the
- Custom button throws and catches the
- Custom No Catch button throws the
CustomException, but doesn't catch it.
- Custom Throw Below calls a function that throws the
CustomException and catches it.
- Custom Throw Catch Below calls a function that throws the
CustomException, catches it, and throws it to be caught by the button code.
That's not all the possibilities, but it gets us started by giving us a chance to experiment with the Exception dialog. To really make the dialog work, make sure to add the
CustomException under the Common Language Runtime Exceptions.
Here it is set up to break whenever the
CustomException is thrown.
And there you go, keep an eye on when the code actually breaks.
Also, if you have multiple projects, you may run into some unusual errors when you start your application. The errors actually make sense, but are beyond this beginner level article. To stop some of the errors, you just have to look them up in the Exception Dialog and set the action to take to "Continue".
That's it folks. Simple.