Chapter 10. Exception Handling

Visual Basic 6 to Visual Basic .NET

Many of the debugging tools in Visual Basic .NET are improvements over the tools found in earlier versions of Visual Basic. However, one of Visual Basic .NET's biggest steps backward, in my opinion, is the loss of edit and continue. In Visual Basic 6 (and earlier versions), you could stop code at any point in time, modify code as needed, and then continue code execution. This made debugging a project considerably less tedious and far more efficient. Unfortunately, this feature did not make it into the first release of Visual Basic .NET. This means, if you encounter a bug while running your project, you'll have to stop the project, change the code, and re-run the project to test your changes. If you're debugging a complex piece of code that requires some set up (such as filling in fields on a form), this can get extremely tedious and time consuming. In order to help compensate, you'll want to adhere to the standards in this book, write as solid code as possible the first time, and make proper use of the debugging tools discussed in this chapter.

Viewing Expression Values by Using Data Tips

Perhaps the simplest debugging aid is data tips. Data tips are very similar to tool tips. To see a data tip, you hover your mouse over an expression while in Break mode, and Visual Basic .NET displays the value of the expression. (See Figure 13-1.) Most people think you can hover over only variables and properties Figure 13-1 shows the value of a property but data tips are a bit more powerful than that. You can actually highlight an expression in code, and if Visual Basic .NET is able to evaluate the expression (the expression doesn't contain a function call, for example), it will show that value in a data tip, as shown in Figure 13-2.

Note

To use data tips, you must be hovering over an expression while in Break mode and in a procedure that is in the current scope.

 

Figure 13-1. Data tips are similar to tool tips.

Figure 13-2. Data tips can be used to view the value of an expression.

Defining Assertions by Using Debug.Assert

Debug.Assert is used to test assumptions while running code within the IDE. You place Debug.Assert statements in specific locations of your code, testing expressions to determine whether they're false. When you compile a project for distribution, Debug.Assert calls are stripped from the code, so Debug.Assert is useful only for debugging a project within the IDE. Debug.Assert serves as a nice backup to your coding chores and should be used to test for conditions that you believe have been accounted for and therefore should not occur. For example, you might expect a variable in a specific location in code to contain a positive number, perhaps because the variable's value is never derived from user input but rather is always passed as a parameter by another section of your code. As such, you might choose not to write validation code to deal with values that fall out of range; such code could add complexity and reduce the efficiency of the methods involved. You know the old saying about making assumptions; making assumptions in code can also be a scary proposition. One thing you can do is set up an assertion using Debug.Assert so that you're immediately notified if your assumption fails. The Debug.Assert method has the following three overloaded formats:

Debug.Assert(expression) Debug.Assert(expression, message) Debug.Assert(expression, message1, message2) 

Debug.Assert is simple to use; however, it's also easy to use incorrectly. In most situations, Visual Basic .NET evaluates expressions looking for True (unless the Not operator is specified). However, Debug.Assert asserts when the expression provided is False; it's easy to forget this when writing code. Consider this statement:

Debug.Assert(intMyValue <> 6) 

Intuitively, it would seem that an assertion occurs whenever intMyValue is not equal to 6 in other words, when the Boolean evaluation of the expression equates to True. In English, you might think this statement equates to:

Assert when intMyVariable is not equal to 6 

In actuality, the Debug.Assert method behaves like this:

Assert when this assumption is not true: intMyVariable <> 6 

Essentially, you're specifying an expression based upon the way things should be; that is, you're stating an assumption. If, for whatever reason, reality deviates from your assumption, an assertion occurs to let you know. Consider that you have a variable whose value should always be between 5 and 500. You can cause an assertion when the value is not what is expected by using this statement:

Debug.Assert(5 <= intMyVariable And intMyVariable <= 500) 

When an assertion occurs, the code enters Break mode at the Debug.Assert statement raising the assertion. (See Figure 13-3.)

Figure 13-3. Assertions stop the execution of code and display a message box like this one.

The Debug.Assert method accepts two optional parameters, both of which are strings to display in the assertion message box. For example, the following statement produces the message box shown in Figure 13-4:

Debug.Assert(x <> 1, "First Message", "Second Message") 

Important

Remember, Debug.Assert statements are removed upon compiling a project for distribution. If you're concerned that the condition you are asserting might exist in build code, you need to account for this fact in your code, such as by correcting a bug or adding validation code.

 

Figure 13-4. You can display custom text in your assertion message boxes.