Exceptions are a sometimes-frustrating part of debugging and developing. You can configure Visual Studio to deal differently with certain exceptions.

When debugging a program in Visual Studio, a number of situations may cause the debugger to enter break mode. When the debugger enters break mode, program execution is suspended, allowing you—the developer—the opportunity to examine and change the program variables. With Visual Studio 2005, you can even alter the program’s underlying source code when in break mode and have the program continue with the edited source.

A common way that break mode is entered is through breakpoints. Another way that break mode is regularly entered is when an exception is raised that is not handled by your application. Any exception that bubbles up out of your user code will cause the Visual Studio debugger to display information about the exception. While you will likely always want to be notified of an unhandled exception when debugging, you may want to break when an exception is thrown, regardless of whether or not it’s handled. Visual Studio can be easily customized to break immediately when a particular type of exception is thrown.

To customize Visual Studio’s behavior when encountering exceptions, go to Debug -> Exceptions or press Ctrl-Alt-E (Debug.Exceptions). This will display the Exceptions dialog.

Exception Dialog

The Exceptions dialog allows you to specify Visual Studio’s behavior when encountering an exception of a specific type. As discussed earlier, the default behavior is to continue when the exception is thrown and to break into the debugger if the exception is not handled. To modify these settings for a particular exception type, simply choose the exception type from the tree of exceptions and customize the radio buttons, indicating the debugger’s behavior.

Understand that changing the setting for a particular exception modifies the behavior for any of those derived exception types whose Use Parent Setting option is selected. By default, all derived exceptions have this Use Parent Setting checked, which means that, by default, changing the behavior of an exception will propagate those changes to its derived exceptions.

SQL statements can be difficult to diagnose and debug. SQL Server does not include any default way to debug and step through a stored procedure, but Visual Studio does. Using the Server Explorer, you can step through the execution of a stored procedure or function right inside of Visual Studio. The first step is to open the Server Explorer and create a data connection to your database.

You will then see the stored procedures and functions of your database listed in the Server Explorer.

From the Server Explorer, you can right-click on a stored procedure or function and you will see a menu item named Step Into Stored Procedure,

When you select Step Into Stored Procedure, you will see the Run Stored Procedure dialog,

After specifying the values for any parameters the stored procedure has, click the OK button. Visual Studio will now execute the stored procedure and open it in the document window, stopping in the first line of execution.

You can now step through the stored procedure as it executes. You can set breakpoints just as you would in normal code—the only limitation is that you can specify only location and hit count breakpoints.

Because T-SQL is inherently different than .NET languages, the debugging experience is a little bit different. Here are some of the limitations with SQL debugging:

• You can use only location and hit count breakpoints in T-SQL stored procedures and functions.

• You cannot use Step Into to step from .NET managed code to T-SQL. You can set breakpoints in the stored procedure though, and the debugger will break when it comes across them.

• You cannot use Break while a SQL statement is already running.

• You can’t use the Set Next Statement function as you might in managed code.

Some other differences are the facts that you can’t use the memory or registers windows, as they just don’t apply to SQL. Unfortunately, SQL Print statements are not shown in the output window either.

You cannot run triggers directly, but you can set breakpoints in triggers, and if they are triggered, Visual Studio will break into their execution on those breakpoints.