Avoiding Bugs

The first step in avoiding or fixing bugs is understanding the three kinds of errors you can encounter:

• Language errors These errors, which are also called syntax errors, are the result of an incorrectly constructed statement. You may have misspelled a reserved word, omitted some necessary punctuation (especially parentheses around arguments to methods), or forgotten to balance statement blocks, such as If and End If or For and Next. Visual Basic detects these errors either when you type the statement or during compilation, before the code executes.
• Run-time errors These errors occur, and are detected by Visual Basic, when a statement attempts an impossible operation while the code is executing. An example of an impossible operation is division by 0 (zero). Suppose you have the following statement:

  
  

  Speed = Miles / Hours
  

  If Hours = 0 (zero), division is an invalid operation even though the statement itself is syntactically correct. The error is a run-time error because the code must execute before Visual Basic can detect the error. Not all run-time errors are easily anticipated or fixed. For example, a "Disk full" error that occurs when you use the Save method could be very difficult to fix.

• Program logic errors Code that contains a program logic error can be both syntactically valid and capable of performing operations that are entirely valid, but still produce incorrect results. Visual Basic cannot detect program logic errors; you must test the code and analyze the results to verify that the code is performing correctly.

Debugging tools are designed to help you analyze run-time errors and Visual Basic code in general, but they're particularly helpful in analyzing program logic errors. These errors can be far more elusive than language errors or run-time errors. For example, an incorrect result may inexplicably be produced at the end of a long series of calculations. When you're debugging, your task is to determine where something went wrong. Perhaps you chose the wrong operator, used the wrong function somewhere, or forgot to initialize a variable.

There are no magic tricks to debugging, and there is no fixed sequence of steps that works every time. Essentially, debugging involves understanding what's going on when your code executes. The better you understand how your code works, the faster you can find and fix bugs. Debugging is easier if you:

• Design your modules carefully by breaking up your code into Sub and Function procedures, with each procedure having a specific, well-defined purpose.
• Include numerous comments. As you go back and analyze your code, you'll understand it much better if you've written comments that describe the purpose of each procedure.
• Use the Option Explicit statement in the declarations section of each of your modules. One of the most common sources of errors is misspelling a variable name. If you have an Option Explicit statement in each module, Visual Basic generates an error message when it discovers a variable that hasn't been explicitly declared. This helps you quickly find misspelled variable names.
• Examine your code to try to find statements that may be causing the problem. Set breakpoints at these statements, and then restart the code. Breakpoints are described in "Entering Break Mode at a Problem Statement" later in this chapter.
• Use the Immediate pane of the Debug window (described later in this chapter) to examine variables and expressions when a breakpoint occurs.