This chapter has already discussed the Err object and has also examined the
options for the On Error statement in Visual Basic. In addition, the error-handling
routines within sub-routines and functions have been mentioned. This section continues
the discussion of errorhandling routines in procedures and recommends some standards
for their creation.
Error-handling routines are sections of code that are executed in the event
of an error. They can range from being very simple with only a few lines of code
to being very lengthy. Unlike inline error handling, using an error-handling routine
enables you to localize all your exception processing in one place within a procedure.
Some things to remember when you code error routines within your Visual Basic
procedures include the following:
-
Keep your error-handling routines simple. If another
error occurs in your error-handling routine, your application will generate a
fatal error and shut down.
-
Error-handling routines are generally found at the end of a procedure.
Make sure that you put an Exit Sub or Exit Function statement before
the error-handling routine so that during normal execution, your program does
not fall through to the error-handling code.
-
Use the On Error Goto <line> statement to control program
flow in the event of an error.
-
Anticipate the types of errors that are common to the functionality
of your code. This will enable you to handle different errors in
different ways. It could also prevent fatal errors from occurring (see "Trappable
Errors" later in this section).
-
If you need to display error messages to users, provide information
useful to them. A user typically does not understand errors such
as Invalid File Format. Instead provide a message that states The file you selected
is not an Excel spreadsheet.
-
When you display error messages to the user, also include information
that will help you—as the developer—track down errors.
Include the form, class, or standard module name. Identify the procedure in which
the error occurred. Add any other additional information that will help you find
and correct problems.
-
Consider logging errors. You might wish to implement
some sort of persistent record of errors (writing to a text file or database,
for example). This will take the burden for error reporting off the user who could
forget or misreport error messages. If you decide to log errors, however, be aware
that logging routines themselves might cause runtime errors (since database and
text file access are prime sources of runtime errors).
-
Whenever possible, give the user the chance to correct problems.
If they try to read a file from a floppy drive and forget to insert
a disk, for example, provide an opportunity for them to retry the operation.
No matter how hard you try, conditions beyond your control will sometimes cause
errors to occur in your application. Using some or all of the preceding tips will
provide a more user-friendly environment for your users. These tips help provide
more information to the user when an error occurs, and will also make it easier
to track down and debug problems in an application.
