Trapping runtime errors

As you can see in the preceding example, when a runtime error occurs, you get two pieces of information in the message box that appears (see Figure 12-12). Note the error number (referred to as Err.Number or the Number property of the Err object in programmer lingo). That number is of no value to a human user but can be handy for a programmer. The other piece of information that the error message provides is the error description, referred to as Err.Description in VBA. The error description is the text that (vaguely) describes why the error occurred.

When you see a runtime error on your screen, two things have actually happened. The obvious first thing is the message onscreen. But behind the scenes, VBA has raised a runtime error, and the Err object has also received two values that describe that error. Those values are stored in the Number and Description properties of the Err object (expressed as Err.Number and Err.Description in VBA code). Just like you can see the number and description of an error by looking at the message onscreen, VBA can "see" that same information by looking at the contents of the Err.Number and Err.Description properties.

Trapping runtime errors is basically a matter of anticipating what runtime errors might occur when the code runs, and also writing code to gracefully handle each type error without causing the whole procedure to crash. The code that you write to deal with runtime errors is often referred to as an error handler because that's exactly what the code does — it handles the error in some way without causing the whole procedure to crash.

umber

Figure 12-12:

Err. Number and Err. Descrip tion in a runtime error.

umber

Figure 12-12:

Err. Number and Err. Descrip tion in a runtime error.

Err.Description

To create an error handler, you first need to add an On Error statement to your code, preferably just after the Sub or Function statement that marks the beginning of the procedure. Use one of the following three different ways to create an On Error statement:

1 On Error GoTo label: When an error occurs as a statement runs, code execution jumps to the section of code identified by label within the same procedure.

1 On Error Resume Next: If an error occurs as a statement runs, that statement is ignored, and processing just continues with the next line of code in the procedure.

1 On Error GoTo 0: Disables any previous OnError GoTo or On Error Resume Next statements so that future runtime errors are handled by VBA rather than your own code.

The Resume statement can be used in any error-handling code to tell VBA exactly where to resume code execution after the runtime error occurred. The syntax for the Resume statement can take any of the following forms:

1 Resume: Causes VBA to re-execute the statement that caused the error. You want to use this statement only if the error-handling code fixed the problem that caused the error in the first place. Otherwise, executing the same statement again just causes the same error again.

1 Resume Next: Causes execution to resume at the first statement after the statement that caused the error. The statement that caused the error does not execute at all.

1 Resume l abel: Causes execution to resume at the label specified.

Code created by Control Wizards and macro conversions might already have error-handling code written into it. For example, say you're working on a form in Design view. You add a command button to the form from the Toolbox while the Control Wizards button is pushed in. As soon as you drop the button in the form, the Command Button Wizard opens so that you can define the button's appearance and behavior one step at a time.

Suppose you go through the wizard and create a button that closes the form. You tell the wizard to name the button, and then you click Finish to complete the wizard. Your form now has a button on it. Although it's not readily apparent in Design view, what the Command Button Wizard really did was write some VBA code that tells the button what to do. To see the code that the wizard wrote, right-click the new button and choose Build Event. The Code window will open showing the code that the wizard wrote for the button's On Click event, as in Figure 12-13.

Figure 12-13:

CloseBttn button and On Click event code.

Figure 12-13:

CloseBttn button and On Click event code.

CloseBttn button

CloseBttn code

CloseBttn button

CloseBttn code

In the CloseBttn_Click() procedure that the wizard created, only the line DoCmd.Close closes the form. Technically, the code would work just fine if DoCmd.Close were the only statement in the entire procedure, but the wizard always adds error handling to the code that it generates. And most of the lines in the procedure are actually there to handle errors in case some problem arises that prevents the form from closing.

Near the top of the procedure, you see the statement On Error GoTo Err_ CloseBttn_Click. When executed, that statement tells VBA, If a runtime error occurs while this procedure is executing, don't "crash." Instead, stop what you're doing and resume execution at the Err_C!oseBttn_Click label.

Then the code tries to execute the next statement, DoCmd.Close. If VBA is able to close the form when executing that statement, no runtime error occurs. Instead, the code execution drops to the next actual statement in the procedure, Exit Sub, which ends the procedure. In other words, if no error occurs when DoCmd.Close executes, the code runs and ends normally without calling upon any error-handling code.

However, if a runtime error does occur when VBA tries to execute the DoCmd. Close statement, the procedure doesn't crash. Rather, it passes control to the first statement under the Err_CloseBttn_Click: label. There, the MsgBox Err.Description statement shows the description of the error in a simple message box, and code execution drops to the line that reads Resume Exit_ CloseBttn_Click:. The first statement under that label reads Exit Sub. When executed, that statement just ends the procedure normally.

A key component of understanding how error handling works is realizing that any line that ends with a colon is a label in code. A label is different from a regular line of code in that it's not an instruction to the computer to do something. Rather, its just a placeholder in code to which GoTo and Resume statements can pass control. The sample CloseBttn_Click procedure has two labels, pointed out in Figure 12-14.

Figure 12-14:

Lines ending with a colon (:) are labels, not statements.

Figure 12-14:

Lines ending with a colon (:) are labels, not statements.

Label Label

A label text can be any text at all, provided that it starts with a letter and contains no blank spaces. Using the word Err and an underscore, followed by the procedure name and a colon, is customary but not required. However, the colon at the end of the label is mandatory because it's the only character that lets the compiler know that the line is a label rather than a regular VBA statement.

0 0

Post a comment