Problem-Solving Techniques

Problem-Solving Techniques

You need to master a number of skills to become effective at debugging. This section explores some of those skills.

Using the System.Diagnostics Library

The System.Diagnostics namespace has three important classes: Debug, Trace, and Debugger. The Debug and Trace classes are related in that you can use both of them to generate debugging information at run time, which is helpful in diagnosing various application problems. Although their functionality is slightly different, both classes support similar interfaces, making it easy to move back and forth between them. However, you might also be confused about when to use one instead of another. The official word from the Microsoft Developer Network (MSDN) documentation is that the Trace class can be used to instrument release builds. Instrumentation allows you to monitor the health of your application running in real-life settings, isolate problems, and fix them without disturbing a running system. You can use the Debug class to print debugging information and check your logic with assertions; you can make your code more robust without affecting the performance and code size of your shipping product.

The Debugger class is somewhat different. It enables communication between your application and an attached debugger. This can be useful for inserting code into your application that assists in debugging complex problems or error scenarios. In addition, some application types (such as Windows services) can be notoriously difficult when you re trying to trace the root of failures. You might find these two particular methods of the Debugger object useful:

• The Log method enables the application to post messages to the attached debugger.

• The Break method enables the application to signal the debugger to break into that line of code. Using this method is analogous to using conditional breakpoints in Visual Basic .NET, except that Break will work with any attached debugger.

Using CorDbg

CorDbg is a managed command-line debugger. It can be extremely useful for handling problems with deployment machines that don t have the Visual Basic .NET debugger installed. We don t recommend this debugger to the casual developer, but the simple commands explained in this section will provide a useful introduction to command-line debugging.

Where Do I Get CorDbg?

CorDbg is located in the %SYSVOL%\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Bin directory when the Framework Software Development Kit (SDK) is installed. You can use the Visual Basic .NET installer to install the SDK, or you can download the SDK from the MSDN Web site.

First you need to start the debugger. If you add the path to the directory containing CorDbg.exe to your environment, you can start the debugger by typing cordbg at the command prompt. The following sequence of commands is typical:

1. Type pro to get a list of managed processes and process IDs.

2. Type at [pid] to attach to the process.

3. Type ca e to catch all exceptions.

4. Type g to continue the program execution.

When an exception occurs, CorDbg breaks to the prompt and reports the exception type. At this stage you can evaluate where the exception occurred, get stack trace information, and inspect variable values.

If command-line debuggers aren t your style, the Framework SDK also provides a GUI debugger (DbgCLR, in the %SYSVOL%\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\GuiDebug directory) that provides a similar debugging experience to the Visual Basic .NET debugger.

Simplifying Complex Expressions

Trying to figure out the cause of an exception in a large compound statement can be a real challenge. When you encounter obtuse errors (either compile or run-time errors), it can be helpful to break down the offending line of code into smaller, isolated statements. There s no penalty for increasing the line count of your application, so why worry? Breaking down complex single-line expressions into several separate expressions can also improve your ability to add run-time error handling to your application.

Let s look at an example of simplifying complex expressions. The following Visual Basic .NET line is a complex expression because there are several statements on one line:

MsgBox(Format(CDate(myString & "/2002")))

If a line like this causes errors and you can t figure out where the error occurs, try simplifying it by putting each statement on a separate line and storing the results of each statement in a temporary variable. The following sample shows how to do this:

Dim tempString, formattedString As String, tempDate As Date tempString = myString & "/2002" tempDate = CDate(tempString) formattedString = Format(tempDate, "d-mmm-yyyy") MsgBox(formattedString)

If an error occurs after you ve made the change, it s simple to determine which statement actually caused the error. We are not suggesting you do this with all your code, but it s a useful technique for tracking down the cause of an error when all you know is that it happens somewhere on a particular line.