• Development of an adequate error handling procedure is application dependent.
You need to know what type of errors you are looking for and what corrective actions
must be taken if these errors are encountered. For example, if a 'divide by zero'
is found, you need to decide whether to skip the operation or do something to
reset the offending denominator.
• What we develop here is
a generic framework for an error handling procedure. It simply informs the user
that an error has occurred, provides a description of the error, and allows the
user to Abort, Retry, or Ignore. This framework is a good starting point for designing
custom error handling for your applications.
• The generic
code (begins with label HandleErrors) is:
HandleErrors:
Select Case MsgBox(Error(Err.Number), vbCritical + vbAbortRetryIgnore, "Error
Number" + Str(Err.Number))
Case vbAbort
Resume ExitLine
Case vbRetry
Resume
Case vbIgnore
Resume Next
End Select
ExitLine:
Exit Sub
Let’s look at what goes on here. First, this routine is only executed
when an error occurs. A message box is displayed, using the Visual
Basic provided error description [Error(Err.Number)] as the message, uses
a critical icon along with the Abort, Retry, and Ignore buttons, and uses the
error number [Err.Number] as the title. This message box returns a response indicating
which button was selected by the user.
If Abort is selected, we simply exit the procedure. (This
is done using a Resume to the line labeled ExitLine. Recall all error trapping
must be terminated with a Resume statement of some kind.)
If Retry is selected, the offending program line is retried
(in a real application, you or the user would have to change something here to
correct the condition causing the error).
If Ignore is selected, program operation continues with the
line following the error causing line.
• To use this generic code in an existing procedure, you need to do three
things:
-
-
-
Copy and paste the error handling code into the end of your procedure.
-
-
Place an Exit Sub line immediately preceding the HandleErrors labeled line.
-
-
Place the line, On Error GoTo HandleErrors, at the beginning of your procedure.
For example, if your procedure is the SubExample seen earlier, the modified
code will look like this:
Sub SubExample()
.
. [Declare variables, ...]
.
On Error GoTo HandleErrors
.
. [Procedure code]
.
Exit Sub
HandleErrors:
Select Case MsgBox(Error(Err.Number), vbCritical + vbAbortRetryIgnore, "Error
Number" + Str(Err.Number))
Case vbAbort
Resume ExitLine
Case vbRetry
Resume
Case vbIgnore
Resume Next
End Select
ExitLine:
Exit Sub
End Sub
Again, this is a very basic error-handling routine. You must determine its
utility in your applications and make any modifications necessary. Specifically,
you need code to clear error conditions before using the Retry option.
• One last thing. Once you've written an error handling routine, you need
to test it to make sure it works properly. But, creating run-time errors is sometimes
difficult and perhaps dangerous. Visual
Basic comes to the rescue! The Visual
Basic Err object has a method (Raise) associated with it that simulates the
occurrence of a run-time error. To cause an error with value Number, use:
Err.Raise Number
• We can use this function to completely test the operation of any error
handler we write. Don’t forget to remove the Raise statement once testing
is completed, though! And, to really get fancy, you can also use Raise to generate
your own ‘application-defined’ errors. There are errors specific to
your application that you want to trap.
• To clear an error condition (any error, not just ones generated with the
Raise method), use the method Clear:
Err.Clear
