C# 4 and .NET 4

400 ❘ ChaPTer 16 visuAl studiO 2010
figure 16-26
exceptions
Exceptions are great when you ship your application and for making sure that error conditions are handled
in an appropriate way within your application. Used well, they can ensure that your application copes with
difficulties well and that the user is never presented with a technical dialog box. Unfortunately, exceptions
are not so great when you are trying to debug your application. The problem is twofold:
➤
➤
If an exception occurs when you are debugging, you often do not want it to be handled
automatically — especially if automatically handling it means retiring gracefully and terminating
execution! Rather, you want the debugger to help you find why the exception has occurred. Of course,
the trouble is that if you have written good, robust, defensive code, your program will automatically
handle almost anything — including the bugs that you want to detect!
If an exception occurs that you have not written a handler for, the .NET runtime will still go off looking
for a handler. However, by the time it discovers that there is not one, it will have terminated your
program. There will not be a call stack left, and you will not be able to look at the values of any of
your variables because they will all have gone out of scope.
Of course, you can set breakpoints in your catch blocks, but that often does not help very much because
when the catch block is reached, flow of execution will, by definition, have exited the corresponding try
block. That means that the variables you probably wanted to examine the values of to figure out what has
gone wrong will have gone out of scope. You will not even be able to look at the stack trace to find
what method was being executed when the throw statement occurred — because control will have left
that method. Setting the breakpoints at the throw statement will of course solve this, except that if you
are coding defensively, there will be many throw statements in your code. How can you tell which one is the
one that threw the exception
In fact, Visual Studio provides a very neat answer to all of this. If you look into the main Debug menu, you
will find a menu item called Exceptions. This item opens the Exceptions dialog box (see Figure 16-27), which
allows you to specify what happens when an exception is thrown. You can choose to continue execution
or to stop and start debugging — in which case execution stops and the debugger steps in at the throw
statement itself.
www.it-ebooks.info