Word Document Properties

Chapter 5: Creating Structured Programs
10_046500 ch05.qxp 12/5/06 5:35 PM Page 131

---

buggy code that is hard to read. In addition, 
GoTo
statements can hide poor
program design. However, the 
GoTo
statement can also accomplish useful
work, so the goal is to avoid misuse of the 
GoTo
statement and concentrate
on useful tasks. Here are some ways to avoid misusing the 
GoTo
statement:
Loops:
Never use a 
GoTo
statement as a loop replacement. The state-
ments used for loops signal others about your intent. In addition, stan-
dard loop statements contain features that keep bugs, such as endless
loops, to a minimum.
Exits:
Avoid using a 
GoTo
statement as a means of exiting a program.
You can always use the 
End
statement for that task.
Program flow problems:
If you detect problems with the flow of your
program, check your pseudo-code and design documents again. Make
sure that you implement the design correctly. The design might require
change as well. Don’t assume that the design is correct, especially if this
is a first attempt.
132
Part II: Learning the Ropes 
10_046500 ch05.qxp 12/5/06 5:35 PM Page 132

---

Chapter 6
Trapping Errors and
Squashing Bugs
In This Chapter
Understanding the various types of bugs
Understanding how to prevent bugs
Figuring out how to track down bugs
Getting to know the Locals window
Getting to know the Watch window
E
ven the best programmer in the world makes mistakes. It’s part of the
human condition. Don’t be surprised when a bug creeps into your well-
designed and well-implemented VBA program. Bugs are the gremlins of the
computer industry — they’re insidious and evil.
Fortunately, you can hunt down bugs and squash them. You can also prevent
bugs from occurring in the first place by coding your VBA program carefully.
The goal of this chapter is to help you understand what you can do to pre-
vent bugs in your VBA program and what to do when they get in anyway.
You won’t figure out how to write perfect programs because no one does. As
a result, you use 
error trapping
to detect bugs and do something about them
before they can cause problems. In the cases where you can’t detect the
bugs, you use 
error handling
to fix the problems that the bugs cause and to
help your VBA programs recover.
11_046500 ch06.qxp 12/5/06 5:35 PM Page 133

---

Knowing the Enemy
Users look at bugs as non-entities devoid of any characteristics. All a user
knows is that a bug causes the program to crash and lose data. You can’t
afford to have that perspective. Bugs have personalities, in that they vary by
Type
Cause
Effect
Severity
Other factors that you include in your personal classification system
Locating a bug means knowing about its personality so that you can find it
quickly. It helps to classify the bug by type. Each bug type has a different
method for prevention and troubleshooting. You can classify bugs into the
following four types:
Syntax
Compile
Run-time
Semantic
The best way to find bugs is to know your coding style. Keeping notes helps
you understand patterns in your programming so that you can correct tech-
niques that lead to bugs. More importantly, understanding your personal
style helps you develop techniques for finding bugs based on past mistakes.
Knowing what you did in the past helps you locate and squash bugs today.
Understanding syntax errors
Syntax errors are the easiest errors to avoid but are also some of the hardest
errors to find. A 
syntax error
can include a spelling mistake, misuse of punctu-
ation, or misuse of a language element. When you forget to include an 
End
If
for an 
If...Then
statement, it’s a syntax error.
Typos are common syntax errors. They’re especially hard to find when you
make them in variable names. For example, VBA views 
MySpecialVariable
and 
MySpecialVaraible
as two different variables, but you might miss the
typing error. Adding 
Option Explicit
to the beginning of every module,
form, and class module that you create eases this problem. (See the upcom-
ing “Understanding compile errors” section for details on using 
Option
134