Avoiding Bugs

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

• Compile errors These errors are the result of an incorrectly constructed statement. You may have mistyped a keyword, omitted some necessary punctuation, or forgotten to balance pairs of statements such as If and End If or For and Next. Visual Basic detects these errors during compilation or when you try to run the code.

  Unless you’ve cleared the Auto Syntax Check check box on the Module tab of the Options dialog box (Tools menu), Visual Basic displays an error message whenever you enter code that contains a syntax error.

• Run-time errors These errors occur, and are detected by Visual Basic, when a statement attempts an impossible operation while the code is running. An example of an impossible operation is division by zero. Suppose you have this statement:

  Speed = Miles / Hours
  

  If the variable Hours is equal to zero, a division by zero error occurs even though the statement itself is syntactically correct. The error is a run-time error because the code must run before Visual Basic can detect the error. Not all run-time errors are easily anticipated or fixed. For example, a “Disk full” error may require you to cancel an update and restore a table to its initial state. If you don’t trap run-time errors, Microsoft Access will stop your code at the place where the error occurred and display the error message associated with that error.

  See Also   For more information on fixing run-time errors, see Chapter 8, “Handling Run-Time Errors.”

• Program logic errors Code containing a program logic error may be syntactically correct and able to perform operations that are entirely valid, but the code may still produce incorrect results. Visual Basic can’t detect program logic errors; you must test the code and analyze the results to verify that the code is performing correctly.

Because successful debugging requires that you understand what’s going on when your code runs, you’ll want to design code that’s easy to analyze. Try the following techniques when designing your code to make the debugging process easier:

• Break up your code into Sub and Function procedures that have specific, well-defined purposes.
• Include plenty of 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.
• Put the Option Explicit statement in each module. This statement makes Visual Basic generate an error message when it discovers a variable that hasn’t been explicitly declared. One of the most common sources of errors is mistyping a variable name. Visual Basic does not automatically require that you explicitly declare variables, but failing to do so can introduce subtle, hard-to-detect errors into your code. To make sure that all variables must be declared before they are used in a procedure, you can have Microsoft Access insert the Option Explicit statement in the Declarations section of every new module in the database. To force explicit variable declaration in this way, open the Options dialog box (Tools menu), click the Modules tab, and select the Require Variable Declaration check box.
• Develop a consistent naming scheme for the variables in your code. You’ll recall the purpose and scope of a variable more quickly if it has a meaningful name. For example, you could use the prefix pint to indicate a public integer variable, or str to indicate a string variable.
• Whenever possible, declare objects and variables with the specific data type you intend to use, instead of using the generic Object or Variant types. This practice, in addition to making your code run faster, causes Visual Basic to report errors if you make an improper assignment or try to perform an invalid operation with the object or variable in your code.