Writing an Exception Handler by Using Try...Catch...Finally

The Visual Basic .NET Debugging Windows

Visual Basic .NET includes a number of windows designed to provide you with all sorts of useful debugging information. Most of these windows provide accurate information only while in Break mode, which is why it's so important to be proficient with breakpoints. Table 13-3 lists the various debugging windows. I provide an overview of some of these windows in the following sections.

Note

Unless otherwise stated, all of these windows can be found on the Windows submenu of the Debug menu.


 

 

Table 13-3. The Debugging Windows and What They Display

Window

Displays

Autos

Variables in the current statement and previous statement

Locals

Local variables

Me

The parent object of the current procedure

Watch

Variables, register contents, and any valid expression recognized by the debugger

QuickWatch

Variables, register contents, and any valid expression recognized by the debugger

Registers

The contents of the registers

Memory

The contents of memory

Call Stack

The names and functions on the call stack, parameter types, and parameter values

Disassembly

Assembly code generated by the compiler

Threads

Information on threads created by your program

Modules

The modules (DLLs and executables) used by your program

 

Note

Debugging threads is beyond the scope of this book, so I won't be covering the Threads window here.


 

Autos Window

The Autos window displays the variables and enumerations used in the current statement (the statement highlighted in yellow that will be executed when execution continues), as well as the variables and enumerations used in the three statements on either side of the current statement. (See Figure 13-14.) It chooses the values to display "automatically," which is how the window got its name. Use the Autos window (found on the Windows submenu of the Debug menu) to quickly get a snapshot of what is happening in the code. Notice in Figure 13-14 that object variables can be expanded so that you can view any and all of their members. In addition, you can double-click the Value column of any item displayed and enter a new value for the item. When you need to see more variables in the current scope, use the Locals window instead.

Figure 13-14. The Autos window gives you a quick snapshot of the variables being used at and near the point of execution.

graphics/f13ln14.jpg

The Autos window (as well as the Locals window) is primarily for use in Break mode. Although it might display data while the application is running, it might not be accurate. When the code enters Break mode, the window is automatically refreshed with the current values.

Warning

MSDN makes the following warning: "Editing floating-point values can result in minor inaccuracies due to decimal-to-binary conversion of fractional components. Even a seemingly innocuous edit can result in changes to some of the least significant bits in the floating-point variable."


 

Locals Window

The Locals window see Figure 13-15 is very similar to the Autos window. The primary difference is that the Locals window shows all variables and objects within the current scope, not just those within three lines of the current execution point. Personally, I find the Locals window (found on the Windows submenu of the Debug menu) an extremely effective debugging tool. As with the Autos window, you can change the v alue of an item in the list by double-clicking its value column and entering a new value. The same caution applies to editing floating-point values, however.

Tip

When deciding whether to use the Autos window or Locals window, use the one with the smallest scope relevant to the problem at hand.


 

Figure 13-15. The Locals window displays all variables and objects in the current scope.

graphics/f13ln15.jpg

Tip

By default, the current scope is used as the context of the Locals window. To use an alternate context, use the Debug Location toolbar. You can also double-click an item in the Call Stack or Threads window to change the context.


 

Me Window

The Me window see Figure 13-16 displays the data members of the object associated with the current method. The contents and behavior of this window are similar to the Autos and Locals windows. As with the other two windows already discussed, you can double-click a value and change it (with the aforementioned caveat on changing floating-point values). Although the contents of Figure 13-16 seem simple enough, expanding the nodes provides a lot of information. Most of it probably won't be useful to you during your debugging sessions. However, if you need the data, you really need the data and the Me window is the best way to get it.

Figure 13-16. The Me window shows all data members of the object associated with the current method.

graphics/f13ln16.jpg

Watch Window

The Watch window is used to evaluate variables and expressions essentially it "watches" the variables or expressions that you specify. You can actually have up to four watch windows open (all of which are opened from the Windows submenu on the Debug menu). To add a variable or expression to the Watch window,

  • Right-click a variable or highlighted expression and choose Add Watch from the context menu, or

  • Drag a variable or highlighted expression in the code editor and drop it on the Watch window, or

  • Drag an item from the Locals or Autos window and drop it on the Watch window, or

  • Enter any valid variable or expression recognized by the debugger into a new line in the Watch window.

When a variable or expression is added to the Watch window, the name (or expression) is listed, along with the current value and the data type. (See Figure 13-17.) Any time you enter a breakpoint, the Watch window is automatically updated. You can change the value of a variable being watched by clicking in the Value column for the variable and entering the new value.

Figure 13-17. The Watch window monitors and evaluates variables and expressions.

graphics/f13ln17.jpg

QuickWatch Window

The QuickWatch window see Figure 13-18 is used sort of as a "scratch" watch window. The QuickWatch window is a modal dialog box, so you have to dismiss it before you can continue debugging, which means it doesn't persist any values. To evaluate an expression in the QuickWatch window, right-click a highlighted expression and choose QuickWatch from the context menu. You can change the expression as needed, and click Recalculate to view the results. If you want to watch the expression on a more permanent basis, click Add Watch; the expression is added to the Watch window.

Figure 13-18. Use the QuickWatch window for a "quick and dirty" evaluation of an expression.

graphics/f13ln18.jpg

Command Window

If you programmed with an earlier version of Visual Basic, you've undoubtedly used the Immediate window. This window no longer exists, but the same functionality is found in the new Command window. (See Figure 13-19.) The Command window is available from the Other Views submenu of the View menu (not from the Debug menus like the other windows discussed in this chapter). The Command window has two modes: Command mode and Immediate mode. Command mode is used to issue Visual Studio .NET commands directly without having to use the menus. The Immediate mode, on the other hand, is used for debugging and closely emulates the Immediate window found in early versions of Visual Basic. Because this chapter is about debugging, I'll focus on the features of the Immediate mode.

Figure 13-19. The Command window is used to execute commands directly in the Visual Basic .NET environment.

graphics/f13ln19.jpg

To display the Command window in Immediate mode, choose Immediate from the Other Windows submenu of the Debug menu. When in Immediate mode, the title bar text of the Command window says "Command Window Immediate" and there is no greater-than symbol prompt. (See Figure 13-20.)

Tip

You can change from Command mode to Immediate mode by typing immed and pressing Enter in the Command window. To switch to Command mode from Immediate mode, type >cmd and press Enter.


 

Figure 13-20. The Immediate mode of the Command window is used for debugging.

graphics/f13ln20.jpg

The Immediate mode of the Command window is used to evaluate expressions, execute statements, print variable values, and even change variable values in some cases. To print the value of a variable, use the ? symbol to represent the word Print, as in:

? intFontSize 

When you press Enter, your command is issued and the result is displayed. (Refer to Figure 13-20.) To change the value of a variable, simply enter the appropriate expression, like this:

intFontSize = 48 

You can also call procedures using the Immediate mode. For example, to print the result of a function, you could use a statement such as this:

? DefaultWarehouse() 

These examples illustrate some of the important debugging tasks for which you'll often use the Command window.

Note

A major difference between the Command window of Visual Basic .NET and the Immediate window of Visual Basic 6 is that you can perform commands in the Command window only while in Break mode.


 

Output Window

The Output window is used by Visual Basic .NET to display status messages, such as success or failure when compiling code. (See Figure 13-21.) Most of the time, the copious amounts of data displayed in the Output window won't be useful to you. Some of the information is more easily dealt with by using other tools. (For example, build errors are easier to deal with by using the Task List window.) Perhaps the most useful feature of the Output window is that you can send text to it at will, which is an extremely important debugging tool. In fact, printing to the Output window is accomplished using the Debug object.

Figure 13-21. The Output window displays lots of status text generated by Visual Basic .NET.

graphics/f13ln21.jpg

To print data to the Output window, use the WriteLine method of the Debug object, like this:

Debug.WriteLine(sngInterest + dblTotal) 

You can print literal text and numbers, variables, enumeration members, or expressions. WriteLine is most useful when you want to know the value of a variable, but you don't want to halt code execution by using a breakpoint. For example, say you have a number of statements that manipulate a variable. You can sprinkle WriteLine statements in the code to print the variable's contents at strategic points. When you do this, you'll want to print some text along with the variable's value so that the output makes sense to you. For example:

Debug.WriteLine("Results of shader calculation = " & _                 sngGipLarefAlgorithm) 

There are many creative uses of the Output window. Just remember that the Output window isn't available to a compiled component; calls to the Debug object are ignored by the compiler when building distributable components.

Task List Window

Visual Basic .NET includes a new tool that (in my opinion) dramatically impacts development: the Task List. The Task List acts as a central repository for things that need to be addressed in your code. You can add items to the Task List as you see fit, and Visual Basic .NET adds items to the list for you as well. To display the Task List, use the Show Tasks submenu of the View menu. (See Figure 13-22.)

Figure 13-22. You can choose exactly what types of tasks are displayed.

graphics/f13ln22.jpg

One instance in which Visual Basic .NET creates a task automatically is when your code has a compile (build) error. Figure 13-23 shows the Task List containing a build error. Notice how the task's description tells you the exact problem. Double-clicking a system-generated task takes you directly to the related statement. (Double-clicking a task that you created has a different effect, as discussed shortly.) If the task exists in a file that isn't loaded, the file is loaded and the related statement is displayed. This greatly simplifies the process of addressing compile errors in code; you can simply work through the list of tasks rather than compile, fix an error, try compiling again, fix the next error, and so on.

Figure 13-23. Compile errors are automatically added to your Task List.

graphics/f13ln23.jpg

In addition to system-generated tasks, you can create your own tasks as often and wherever needed. In the past, it was common to place certain comments such as TODO: in code where you needed to address something. In order to address these issues, you had to perform a text search in your code, which was a highly inefficient process. In truth, such comments were often forgotten, and therefore important coding chores were left unfinished.

Now you can add a task to your Task List wherever you need to, rather than just enter a comment that means something only to you. To create a task, right-click the statement to which you want to attach the task and choose Add Task List Shortcut from the context menu. Visual Basic .NET creates a task shortcut at the statement, indicated by a blue arrow in the left margin of the code window, and it adds the task to the Task List window. (See Figure 13-24.) By default, the description of the task is set to the actual code statement you flagged. To change this text, click the description of the task in the Task List to put it in edit mode and then change the text. Double-click the shortcut arrow next to the task in the Task List (the arrow is similar to the one that appears in the left margin of the code window) to go to directly to the statement to which a task is attached. Notice that this is different from how you display the statement for a system-generated task.

Figure 13-24. A statement with an associated task has a blue arrow next to it.

graphics/f13ln24.jpg

Tasks don't have to be associated with a code statement. To create a task that isn't attached to code, click the first row of the Task List (where it says Click here to add a new task) and enter the new task description. To delete a task you've created, right-click the task in the Task List and choose Delete from the context menu. If you simply want to mark a task as completed rather than deleting it from your Task List, click the check box next to the description.

Note

You can't delete a task that was created by Visual Basic .NET as a result of a build error; you must correct the error to make the task go away.


 

Modules Window

The Modules window acts as a "process viewer," listing the modules (DLLs and executables) used by the program. (See Figure 13-25.) The Modules window shows you the order in which the modules were loaded, in addition to each module's version, timestamp, address, and path. The Modules window makes it easy to check the version and location of files being used while debugging, which might be useful to compare to files on other machines that are experiencing problems. You can sort on any column in the list simply by clicking a column header.

Figure 13-25. Use the Modules window to see details of all DLLs and executables used by your program.

graphics/f13ln25.jpg

Memory Window

The Memory window displays a memory dump at the current address of execution. (See Figure 13-26.) You can use the Memory window to view large buffers and strings and follow a point through memory, but for the most part you need to be familiar with assembly language programming to make any use of the Memory window.

Figure 13-26. Effectively using the Memory window requires knowledge of assembly language programming.

graphics/f13ln26.jpg

Call Stack Window

The Call Stack window shows you the names of all functions on the call stack. (See Figure 13-27.) By default, Visual Basic .NET displays the following information for each function, in addition to the function's name.

  • Module Name

  • Parameter Names

  • Parameter Types

  • Parameter Values

  • Line Number

  • Byte Offset

You can hide any or all of this additional information by right-clicking the Call Stack window and selecting the appropriate menu item. (See Figure 13-28.)

Figure 13-27. Use the Call Stack window to see details of all functions on the call stack.

graphics/f13ln27.jpg

Figure 13-28. Use the Call Stack's shortcut menu to tailor the display.

graphics/f13ln28.jpg

 

Goals of Debugging

The goals of debugging applications include

  • Isolating and identifying bugs as quickly as possible

  • Effectively using all of the debugging tools available

 



Practical Standards for Microsoft Visual Basic. NET
Practical Standards for Microsoft Visual Basic .NET (Pro-Developer)
ISBN: 0735613567
EAN: 2147483647
Year: 2005
Pages: 84

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net