Nbsp;   Debugging Exceptions

The Visual Studio debugger offers special support for exceptions. With a solution open, choose Ex- ceptions from the Debug menu, and you’ll see the dialog box shown in Figure 20-4.

FIGURE 20-4The Exceptions dialog box, showing the different kinds of exceptions.

This dialog box shows the different kinds of exceptions that Visual Studio is aware of. For Com- mon Language Runtime Exceptions, expanding the corresponding branch in the dialog box, as in Figure 20-5, shows the set of namespaces that the Visual Studio debugger is aware of.

FIGURE 20-5The Exceptions dialog box, showing CLR exceptions by namespace.

If you expand a namespace, you’ll see all of the System.Exception-derived types defined within

that namespace. For example, Figure 20-6 shows what you’ll see if you open the System namespace.

For any exception type, if its Thrown check box is selected, the debugger will break as soon as that exception is thrown. At this point, the CLR has not tried to find any matching catch blocks. This is useful if you want to debug your code that catches and handles an exception. It is also useful when you suspect that a component or library may be swallowing or re-throwing exceptions, and you are uncertain where exactly to set a break point to catch it in the act.

FIGURE 20-6The Exceptions dialog box, showing CLR exceptions defined in the System namespace.

If an exception type’s Thrown check box is not selected, the debugger will also break where the exception was thrown, but only if the exception type was not handled. Developers usually leave the Thrown check box cleared because a handled exception indicates that the application anticipated the situation and dealt with it; the application continues running normally.

If you define your own exception types, you can add them to this dialog box by clicking Add. This

causes the dialog box in Figure 20-7 to appear.

FIGURE 20-7Making Visual Studio aware of your own exception type: the New Exception dialog box.

In this dialog box, you first select the type of exception to be Common Language Runtime Excep- tions, and then you can enter the fully qualified name of your own exception type. Note that the type you enter doesn’t have to be a type derived from System.Exception; non–CLS-compliant types are fully supported. If you have two or more types with the same name but in different assemblies, there is no way to distinguish the types from one another. Fortunately, this situation rarely happens.

If your assembly defines several exception types, you must add them one at a time. In the future, I’d like to see this dialog box allow me to browse for an assembly and automatically import all Exception-derived types into Visual Studio’s debugger. Each type could then be identified by as- sembly as well, which would fix the problem of having two types with the same name in different assemblies.

Date: 2016-03-03; view: 685