Central Exception Handlers

Directives

13.1 Start a project without debugging rather than remove or disable debug code.

If you want to run a project as an end-user would (without calls to the Debug object, without stopping at breakpoints, and so forth), select Start Without Debugging from the Debug menu or press Ctrl+F5. Doing so disables the debugger so that you see exactly what an end-user would see, and you don't have to concern yourself with commenting Debug calls and disabling breakpoints.

13.2 Don't create an expression that modifies data when calling Debug.Assert.

When writing an expression for Debug.Assert, make sure that the expression doesn't alter any data within the procedure. If it does, the results you experience while debugging might not be the same as those experienced by a user of your program. To summarize (not so well) the Heisenberg uncertainty principle of quantum physics: the presence of the observer changes the nature of the observed (that and something about a dead cat in an unopened box). Forget about the cat for a moment and consider the following statement:

Debug.Assert(CustomerInterestRate(lngCustomerID) > 8.5) 

If the function CustomerInterestRate modifies any module, global, or static data or if it persists information to a data store, the Debug.Assert call actually changes the state of the application. This change of state won't be present in the build code, however, because Debug calls aren't compiled into distributable components. Essentially, you should avoid making any function calls (even apparently "safe" ones) when calling Debug.Assert.

Incorrect:

' Assert if more than 50 users are in the database. Debug.Assert(TestConcurrentUsers() > 50) 

Correct:

' Assert if more than 50 users are in the database. ' Note that the behavior of the release version will ' be the same as the debug version, because the function ' is called in both. Dim intUserCount As Integer = TestConcurrentUsers() Debug.Assert(intUserCount > 50) 

13.3 Specify custom assertion text when the purpose of the assertion isn't obvious.

When you create an assertion that evaluates a complicated expression, specify optional text to display if the assertion occurs. That way, the purpose of the assertion becomes obvious to any developer that receives the assertion.

Incorrect:

Debug.Assert(objFont.Name = "Courier" And objFont.Size < 8) 

Correct:

Debug.Assert(objFont.Name = "Courier" And objFont.Size < 8, _              "Point size too small for Courier font!") 

13.4 Use Option Strict whenever possible.

Although this was covered in detail in Chapter 5, "Variables," it bears repeating here. With Option Strict turned on, your code will contain fewer bugs because the compiler takes on some of your debugging duties.

13.5 Add exception handling to all of your procedures

In Chapter 10, "Exception Handling," I discussed in detail how to create exception-handling code. The more robust your error handlers, the easier it is to isolate and identify bugs.

13.6 Use the inherent DEBUG constant for conditionally compiled debug code.

Earlier in this chapter, I noted that Visual Basic .NET includes a built in compiler constant: DEBUG. When creating conditionally compiled debug code, use this predefined constant than rather than create one of your own.

Incorrect:

#Const IncludeDebugCode = True #If IncludeDebugCode Then        ' Place debug code here. #End If 

Correct:

#If DEBUG Then        ' Place debug code here. #End If 

13.7 Use breakpoints to ensure that all parts of a complicated procedure have been executed.

One of the most common debugging mistakes is not debugging all of a procedure. When you write a complex procedure with many If End If or Select Case structures, it's relatively easy to miss testing all of the code because of the necessity to create all of the conditions to hit all branches of code. One approach to this problem is to place a breakpoint in each of the conditional blocks of code (after every If statement, Else statement, and so on). As execution hits a breakpoint, remove the breakpoint. When you've removed all of the breakpoints in the procedure, you know that you've tested the code in all possible conditions within the procedure.

13.8 When possible, use a breakpoint instead of a Stop statement.

A Stop statement halts code execution and enters Break mode much like a breakpoint. The primary difference is that Stop statements get compiled into release code. A Stop statement can drop a user to the desktop one of the worst possible scenarios. For this reason, it's best to use a breakpoint in place of a Stop statement whenever possible. The breakpoint won't compile into the release code, and you can use the Breakpoints window to easily locate and manage the breakpoint.

13.9 Create TODO tasks for things that still need to be addressed.

One way to create a task in the Task List is to create a comment that begins with the word TODO. Such comments are automatically added to the Task List as type Comment. You can filter the Task List for comments by right-clicking the Task List and choosing Comment from the Show Tasks submenu as shown in Figure 13-29. TODO tasks provide a consistent mechanism for noting and addressing issues in your code.

Figure 13-29. Comments that start with TODO are easily filtered in the Task List.