41.11. Exceptions

Visual Studio 2008 has a sophisticated exception handler that provides you with a lot of useful information. Figure 41-15 shows the exception assistant dialog that appears when an exception is raised. In addition to providing more information, it also displays a series of actions. The Actions list varies depending on the type of exception being thrown. In this case, the two options are to view details of the exception or copy it to the clipboard.

Figure 41.15. Figure 41-15

If you select the View Detail action item from the exception, you are presented with a modal dialog that provides a breakdown of the exception that was raised. Figure 41-16 shows the attributes of the exception, including the StackTrace, which can be viewed in full by clicking the down arrow to the right of the screen.

Figure 41.16. Figure 41-16

Of course, there are times when exceptions are used to control the execution path in an application. For example, some user input may not adhere to a particular formatting constraint, and instead of using a regular expression to determine whether it matches, a parse operation has been attempted on the string. When this fails, it raises an exception, which can easily be trapped without stopping the entire application.

By default, all exceptions are trapped by the debugger, because they are assumed to be exceptions to the norm that shouldn't have happened. In special cases, such as invalid user input, it may be important to ignore specific types of exceptions. This can be done via the Exceptions window, accessible from the Debug menu.

Figure 41-17 shows the Exceptions window, shown by selecting Debug Exceptions, which lists all the exception types that exist in the .NET Framework. For each exception there are two debugging options. The debugger can be set to break when an exception is thrown regardless of whether it is handled. If the Just My Code option has been enabled, checking the "User-unhandled" box causes the debugger to break for any exception that is not handled within a user code region. More information on Just My Code is provided in Chapter 43, which examines debugging attributes.

Figure 41.17. Figure 41-17

Unfortunately, the Exceptions window doesn't pick up any custom exception types that you may have created, but you can add them manually using the Add button in the lower-right corner of the window. You need to ensure that you provide the full class name, including the namespace; otherwise, the debugger will not break on handled exceptions. Clearly, unhandled exceptions will still cause the application to crash.

41.11.1. Customizing the Exception Assistant

As with a lot of the configurable parts within Visual Studio 2008, the information displayed by the Exception Assistant is stored in an XML file (C:Program FilesMicrosoft Visual Studio 9.0Common7IDEExceptionAssistantContent1033DefaultContent.xml). This file can be modified either to alter the assistant information for existing exception types or to add your own custom exception types. If you have your own exception types, it is better practice to create your own XML document. Simply placing it in the same directory as the DefaultContent.xml is sufficient to register it with Visual Studio for the next time your application is debugged. An example XML file is provided in the following code listing:

<?xml version="1.0" encoding="utf-8" ?>
<AssistantContent Version="1.0" xmlns="urn:schemas-
   microsoft-com:xml-msdata:exception-assistant-content">
    <ContentInfo>
        <ContentName>Additional Content</ContentName>
        <ContentID>urn:exception-content-microsoft-
   com:visual-studio-7-default-content</ContentID>
        <ContentFileVersion>1.0</ContentFileVersion>
        <ContentAuthor>David Gardner</ContentAuthor>
        <ContentComment>Additional Exception Assistant
   Content for Visual Studio 9.0.</ContentComment>
    </ContentInfo>
    <Exception>
        <Type>DebugApp1.myException</Type>
        <Tip HelpID="http://www.professionalvisualstudio.com/MyExceptionHelp.htm">
            <Description>Silly error, you should know better...</Description>
        </Tip>
    </Exception>
</AssistantContent>

This example registers help information for the exception type myException. The HelpID attribute is used to provide a hyperlink for more information about the exception. When this exception is raised, the debugger displays the window (see Figure 41-18).

Figure 41.18. Figure 41-18

41.11.2. Unwinding an Exception

In Figure 41-19 there is an additional item in the Actions list of an exception helper window, which is to enable editing. This is effectively the capability to unwind the execution of the application to just before the exception was raised. In other words, you can effectively debug your application without having to restart your debugging session.

Figure 41.19. Figure 41-19

The "Enable editing" option will only appear if you have configured Visual Studio to break when an exception is thrown, as discussed earlier in this chapter. As with many of the debugging features, both the Exception Assistant and the capability to unwind exceptions can also be disabled via the Debugging tab of the Options window.

An alternative way to unwind the exception is to select the Unwind to This Frame item from the right-click context menu off the Call Stack window after an exception has been raised. This can be useful to check what the state of the application was just before the exception was thrown. You can only unwind an exception if it is handled (that is, contained within a try...catch block). You should also ensure that the debugger is set to break when the exception is thrown. You can do this via the Debug Exceptions window.