Chapter 23: Handling Errors and Exceptions
823
FIGURE 23.2
Built-in error messages usually are not helpful.
The error in Figure 23.2 occurs because the procedure declares and creates a string variable and a
numeric variable and then tries to assign the numeric variable the value of the text string. The type
mismatch occurs because you can’t assign nonnumeric characters to a numeric variable.
The error message in Figure 23.2 reports Runtime error ‘13’, which happens to be a type
mismatch. Unless you know the cause of this problem, how does this message help you? Without a
great deal of experience, how does the user know how to fix this type of problem? In fact, how do
you determine what caused the problem? Clearly, this message box is not much help to a user who
has entered character data into a text box that should be filled with a numeric value.
Notice the Debug button in Figure 23.2. The Debug button stops the program, opens the VBA
code editor, and places a breakpoint on the offending statement (see Chapter 14 for more on
breakpoints). The program is in a state of limbo. All the values of temporary variables are intact,
and you can view them to help you solve the error. The End button causes the program to stop
running, and the user can’t use any tools to check the problem.
The error dialog box shown in Figure 23.2 appears for untrapped errors. This type of message can
be good for development because problems can be traced to the specific line of code that caused
the error. When you click the Debug button, the VBA window opens and highlights the guilty line
of code. But this isn’t the kind of interaction you generally want between your application’s code
and end users. For this reason, having an error handler in the VBA code and making the problem a
handled error is much better. You may be able to prevent the user from seeing a problem by auto-
matically taking corrective action as part of an error handler.
When unanticipated application errors occur
The last type of runtime error is the unknown or unanticipated application error. This is most
often caused by a logical error in the code. Often, no error is displayed because the program is
working exactly the way it was designed. For example, an endless loop occurs if you forget to
advance a record pointer as you traverse a recordset or the condition ending a Do.Loop never