More on Testing and Debugging an ASP.NET 2.0 Application

How to use the Exception Assistant

As you test an ASP.NET application, you may encounter runtime errors that prevent an application from executing. When that happens, an exception is thrown. In many cases, the application anticipates these exceptions and provides code to catch them and process them appropriately. If an exception is not caught, however, the application enters break mode and the Exception Assistant displays a dialog box like the one shown in figure 4-8.

As you can see, the Exception Assistant dialog box indicates the type of exception that occurred and points to the statement that caused the error. In many cases, this information is enough to determine what caused the error and what should be done to correct it. For example, the Exception Assistant dialog box in this figure indicates that an input string value was not in the correct format. The problem was encountered in this line of code for the Order page:

  item.Quantity =
Convert.ToInt32(txtQuantity.Text);

Based on that information, you can assume that the Text property of the txtQuantity control contains a value that can’t be converted to an integer, since the Quantity property of the item object is declared as an integer. This could happen if the application didn’t check that the user entered an integer value into this control. (To allow this error to occur, I disabled the range validator for the Quantity text box on the Order page.)

Many of the exceptions you’ll encounter will be system exceptions like the one shown here. These exceptions apply to general system operations such as arithmetic operations and the execution of methods. If your applications use ADO.NET, you can also encounter ADO.NET and data provider exceptions. If the connection string for a database is invalid, for example, a data provider exception will occur. And if you try to add a row to a data table with a key that already exists, an ADO.NET error will occur.

In some cases, you won’t be able to determine the cause of an error just by analyzing the information in the Exception Assistant dialog box. Then, to get more information about the possible cause of an exception, you can use the list of troubleshooting tips in this dialog box. The items in this list are links that display additional information in a Help window. You can also use the other links in this dialog box to search for more help online, to display the content of the exception object, and to copy the details of the exception to the clipboard.

If you still can’t determine the cause of an error, you can use the Visual Studio debugger to help you locate the problem. You’ll learn how to do that next.

An Exception Assistant dialog box

Figure 4-8.  How to use the Exception Assistant

Description

• If an uncaught exception occurs in an ASP.NET application, the application enters break mode and the Exception Assistant displays a dialog box like the one shown above.
  
• The Exception Assistant provides the name and description of the exception, and it points to the statement in the program that caused the error. It also includes a list of troubleshooting tips. You can click on these tips to display additional information in a Help window.
  
• The information provided by the Exception Assistant is often all you need to determine the cause of an error. If not, you can close this window and then use the debugging techniques presented in this chapter to determine the cause.
  
• If you continue program execution after an exception occurs, ASP.NET terminates the application and sends a Server Error page to the browser. This page is also displayed if you run an application without debugging. It provides the name of the application, a description of the exception, and the line in the program that caused the error. It also includes a stack trace that indicates the processing that led up to the error.

How to use the debugger

 
The topics that follow introduce you to the basic techniques for using the Visual Studio debugger to debug an ASP.NET application. Note that these techniques are almost identical to the techniques you use to debug a Windows application. If you’ve debugged Windows applications, then, you shouldn’t have any trouble debugging web applications.

How to use breakpoints

Figure 4-9 shows how to use breakpoints in an ASP.NET application. Note that you can set a breakpoint before you run an application or as an application is executing. Remember, though, that an application ends after it generates a page. So if you switch from the browser to Visual Studio to set a breakpoint, the breakpoint won’t be taken until the next time the page is executed. If you want a breakpoint to be taken the first time a page is executed, then, you’ll need to set the breakpoint before you run the application.

After you set a breakpoint and run the application, the application enters break mode before it executes the statement that contains the breakpoint. In this illustration, for example, the application will enter break mode before it executes the statement that caused the exception in figure 4-8 to occur. Then, you can use the debugging features described in the topics that follow to debug the application.

In some cases, you may want to set more than one breakpoint. You can do that either before you begin the execution of the application or while the application is in break mode. Then, when you run the application, it will stop at the first breakpoint. And when you continue execution, the application will execute up to the next breakpoint.

Once you set a breakpoint, it remains active until you remove it. In fact, it remains active even after you close the project. If you want to remove a breakpoint, you can use one of the techniques presented in this figure.

You can also work with breakpoints from the Breakpoints window. To disable a breakpoint, for example, you can remove the check mark in front of the breakpoint. Then, the breakpoint isn’t taken until you enable it again. You can also move to a breakpoint in the Code Editor window by selecting the breakpoint in the Breakpoints window and then clicking on the Go To Source Code button at the top of this window, or by right-clicking the breakpoint in the Breakpoints window and choosing Go To Source Code from the shortcut menu.

The Order page with a breakpoint

Figure 4-9.  How to use breakpoints

How to set and clear breakpoints

1. To set a breakpoint, click in the margin indicator bar to the left of the statement where you want the break to occur. The statement will be highlighted and a breakpoint indicator (a large dot) will appear in the margin. You can set a breakpoint before you run an application or while you’re debugging the application.
   
2. To remove a breakpoint, click the breakpoint indicator. To remove all breakpoints at once, use the Debug->Clear All Breakpoints command.
   
3. To temporarily disable breakpoints, use the Debug->Disable All Breakpoints command. You can later enable the breakpoints by using Debug->Enable All Breakpoints.

Description

1. When ASP.NET encounters a breakpoint, it enters break mode before it executes the statement on which the breakpoint is set. From break mode, you can use the debugger to determine the cause of an error.
   
2. The current breakpoints are listed in the Breakpoints window (Debug->Windows-> Breakpoints). You can use the toolbar at the top of this window to work with the breakpoints, and you can use the check box next to a breakpoint to enable or disable the breakpoint.
   
3. You can’t set breakpoints on blank lines or comments.

How to use tracepoints

 
In addition to breakpoints, Visual Studio 2005 provides a new feature called tracepoints. A tracepoint is a special type of breakpoint that performs an action when it’s encountered. Figure 4-10 shows how tracepoints work.

To set a tracepoint, you use the When Breakpoint Is Hit dialog box to indicate what you want to do when the tracepoint is encountered or “hit.” In most cases, you’ll use the Print a Message option to display a message in the Output window. As indicated in this dialog box, the message can include variable values and other expressions as well as special keywords.

For example, the message shown here will include the value of the SelectedValue property of the ddlProducts control. You can see the output from this tracepoint in the Output window in this figure. Here, the first tracepoint message was displayed the first time the page was requested. The second message was displayed when a product was selected from the drop-down list. And the third message was displayed when a quantity was entered and the Add to Cart button was clicked.

Notice that the Output window is also used to display Visual Studio messages like the first, second, and fifth messages shown in this figure. Because of that, this window is displayed automatically when you run an application. If you ever close it and want to reopen it without running the application, however, you can do that using the View->Output command.

To run a macro when a tracepoint is encountered, you select the Run a Macro option. Then, the drop-down list becomes available and you can select the macro you want to run from this list.

By default, program execution continues after the tracepoint action is performed. If that’s not what you want, you can remove the check mark from the Continue Execution option. Then, the program will enter break mode when the tracepoint action is complete.

After you set a tracepoint on a statement, the statement will be highlighted and a breakpoint indicator will appear in the margin. If program execution will continue after the tracepoint action is performed, the indicator will appear as a large diamond. If the program will enter break mode, however, the same indicator is used as for a standard breakpoint.

The Order page with a tracepoint and the dialog box used to set it

Figure 4-10.  How to use tracepoints

Output from the tracepoint in the Output window

Description

• A tracepoint is a special type of breakpoint that lets you perform an action. When ASP.NET encounters a tracepoint, it performs the specified action and then continues execution if the Continue Execution option is selected or enters break mode if it isn’t.
  
• You typically use tracepoints to print messages to the Output window. A message can include text, values, and special keywords. You can also use tracepoints to run macros.
  
• To set a tracepoint, right-click on the statement where you want it set and choose Breakpoint->Insert Tracepoint. Then, complete the When Breakpoint Is Hit dialog box and click OK. You can also convert an existing breakpoint to a tracepoint by right-clicking on its indicator and choosing When Hit.
  
• If program execution will continue after the tracepoint action is performed, the tracepoint will be marked with a large diamond as shown above. Otherwise, it will be marked just like any other breakpoint.

How to work in break mode
 
Figure 4-11 shows the Order page in break mode. In this mode, the next statement to be executed is highlighted. Then, you can use the debugging information that’s available to try to determine the cause of an exception or a logical error.

For example, you can place the mouse pointer over a variable, property, or expression to display its current value in a data tip. You can also display the values of the members of an array, structure, or object. To do that, place the mouse pointer over the array, structure, or object to display its data tip, and then point to the plus sign in that data tip. In this figure, for example, you can see the current values of the members of the Product object named selectedProduct.

You can also use a data tip to change the value of a variable or property. To do that, just right-click the data tip and then choose Edit Value from the shortcut menu. When you do, the value that’s displayed will become editable so you can enter a new value.

You can also see the values of other properties and variables in the Autos window near the bottom left of the Visual Studio window. You’ll learn more about the Autos window and some of the other debugging windows in a minute.

The Shopping Cart application in break mode

 Figure 4-11.  How to work in break mode

Description

• When you enter break mode, the debugger highlights the next statement to be executed.
  
• You can use the debugging windows and the buttons in the Debug menu and toolbar to control the execution of the program and determine the cause of an exception.
  
• To display the value of a variable or property in a data tip, position the mouse pointer over the variable or property in the Code Editor window. To display a data tip for an expression, highlight the expression and then point to it. The expression must not contain a method call.
  
• To display the members of an array, structure, or object in a data tip, position the mouse pointer over it to display its data tip, and then point to the plus sign in the data tip.
  
• To change the value of a variable in a data tip, right-click the data tip, choose Edit Value, and then enter the new value.
  
• To continue program execution, press F5 or click the Continue button in the Standard or Debug toolbar. For more options about controlling program execution, see figure 4-12.

How to control the execution of an application

 
Once you’re in break mode, you can use a variety of commands to control the execution of the application. These commands are summarized in figure 4-12. As you can see, most of these commands are available from the Debug menu or the Debug toolbar, but three of them are available only from the shortcut menu for the Code Editor window. You can also use shortcut keys to start some of these commands.

To execute the statements of an application one at a time, you use the Step Into command. When you use this command, the application executes the next statement, then returns to break mode so you can check the values of properties and variables and perform other debugging functions. The Step Over command is similar to the Step Into command, but it executes the statements in called methods without interruption (they are “stepped over”).

The Step Out command executes the remaining statements in a method without interruption. When the method finishes, the application enters break mode before the next statement in the calling method is executed.

To skip over code that you know is working properly, you can use the Run To Cursor or Set Next Statement command. You can also use the Set Next Statement command to rerun lines of code that were executed before an exception occurred. And if you’ve been working in the Code Editor window and have forgotten where the next statement to be executed is, you can use the Show Next Statement command to move to it.

If your application gets caught in a processing loop so it keeps executing indefinitely without generating a page, you can force it into break mode by choosing the Debug->Break All command. This command lets you enter break mode any time during the execution of an application.

Commands in the Debug menu and toolbar

Figure 4-12.  How to control the execution of an application

Commands in the Code Editor window’s shortcut menu

Command	Function
Run to Cursor	Execute the application until it reaches the statement that contains the insertion
point.
Set Next Statement	Set the statement that contains the insertion point as the next statement to be
	executed.
Show Next Statement	Move the insertion point to the next statement that will be executed.

Description

• Once the application enters break mode, you can use the Step Into, Step Over, Step Out, and Run To Cursor commands to execute one or more statements and return to break mode.
  
• To alter the normal execution sequence of the application, you can use the Set Next Statement command. Just place the insertion point in the statement you want to execute next, issue this command, and click the Continue button to continue application execution.
  
• To stop an application that’s caught in a loop, switch to the Visual Studio window and use the Debug->Break All command.

How to use the Autos, Locals, and Watch windows to monitor variables
 
If you need to see the values of several application variables or properties, you can do that using the Autos, Locals, or Watch windows. By default, these windows are displayed in the lower left corner of the IDE when an application enters break mode. If they’re not displayed, you can display them by selecting the appropriate command from the Debug->Windows menu. Note that you can display up to four separate Watch windows.

The content of the Autos, Locals, and Watch windows is illustrated in figure 4-13. The difference between the Autos and Locals windows is in the amount of information they display and the scope of that information.

The Locals window displays information about the variables and controls within the scope of the current method. Since that includes information about the form and all of the controls on the form if the code in a form is currently executing, that information can be extensive.

In contrast, the Autos window displays information about the variables, properties, and constants used in the current statement, the three statements before that statement, and the three statements after that statement. Although the information in this window is more limited than the information shown in the Locals window, the Autos window helps you focus on the variables that are relevant to the current statement.

Unlike the Autos and Locals windows, the Watch windows let you choose the values that are displayed. The Watch window shown in this figure, for example, displays the Text property of the txtQuantity and lblUnitPrice controls, the Quantity property of the item object, and the UnitPrice property of the Product object that’s stored in the item object. The Watch windows also let you watch the values of expressions you specify. Note that an expression doesn’t have to exist in the application for you to add it to a Watch window.

To add an item to a Watch window, you can type it directly into the Name column. Alternatively, if the item appears in the Code Editor window, you can highlight it in that window and then drag it to a Watch window. You can also highlight the item in the Code Editor or a data tip and then right-click on it and select the Add Watch command to add it to the Watch window that’s currently displayed.

Besides displaying the values of variables and properties, you can use the Autos, Locals, and Watch windows to change these values. To do that, you simply double-click on the value you want to change and enter a new value. Then, you can continue debugging or continue the execution of the application.

The Autos window

Figure 4-13.  How to use the Autos, Locals, and Watch windows to monitor variables

The Locals window

A Watch window

Description

1. The Autos window displays information about variables, properties, and constants in the current statement and the three statements before and after the current statement.
   
2. The Locals window displays information about the variables and controls within the scope of the current method.
   
3. The Watch windows let you view the values of variables and expressions you specify, called watch expressions. You can display up to four Watch windows.
   
4. To add a watch expression, type a variable name or expression into the Name column, highlight a variable or expression in the Code Editor window and drag it to the Watch window, or right-click on a variable or highlighted expression in the Code Editor window or a data tip and choose Add Watch.
   
5. To delete a row from a Watch window, right-click the row and choose Delete Watch. To delete all the rows in a Watch window, right-click the window and choose Select All to select the rows, then right-click and choose Delete Watch.
   
6. To display any of these windows, click on its tab if it’s visible or select the appropriate command from the Debug->Windows menu.
   
7. To change the value of a property or variable from any of these windows, double-click on the value in the Value column, then type a new value and press the Enter key.

Please check back next week for the conclusion of this article.

blog comments powered by Disqus