From VBA help file:
On Error Statement
Enables an error-handling routine and specifies the location of the routine
within a procedure; can also be used to disable an error-handling routine.
Syntax
On Error GoTo line
On Error Resume Next
On Error GoTo 0
The On Error statement syntax can have any of the following forms:
Statement Description
On Error GoTo line Enables the error-handling routine that starts at
line specified in the required line argument. The line argument is any line
label or line number. If a run-time error occurs, control branches to line,
making the error handler active. The specified line must be in the same
procedure as the On Error statement; otherwise, a compile-time error occurs.
On Error Resume Next Specifies that when a run-time error occurs,
control goes to the statement immediately following the statement where the
error occurred where execution continues. Use this form rather than On Error
GoTo when accessing objects.
On Error GoTo 0 Disables any enabled error handler in the current
procedure.
Remarks
If you don't use an On Error statement, any run-time error that occurs is
fatal; that is, an error message is displayed and execution stops.
An "enabled" error handler is one that is turned on by an On Error
statement; an "active" error handler is an enabled handler that is in the
process of handling an error. If an error occurs while an error handler is
active (between the occurrence of the error and a Resume, Exit Sub, Exit
Function, or Exit Property statement), the current procedure's error handler
can't handle the error. Control returns to the calling procedure. If the
calling procedure has an enabled error handler, it is activated to handle
the error. If the calling procedure's error handler is also active, control
passes back through previous calling procedures until an enabled, but
inactive, error handler is found. If no inactive, enabled error handler is
found, the error is fatal at the point at which it actually occurred. Each
time the error handler passes control back to a calling procedure, that
procedure becomes the current procedure. Once an error is handled by an
error handler in any procedure, execution resumes in the current procedure
at the point designated by the Resume statement.
Note An error-handling routine is not a Sub procedure or Function
procedure. It is a section of code marked by a line label or line number.
Error-handling routines rely on the value in the Number property of the Err
object to determine the cause of the error. The error-handling routine
should test or save relevant property values in the Err object before any
other error can occur or before a procedure that might cause an error is
called. The property values in the Err object reflect only the most recent
error. The error message associated with Err.Number is contained in
Err.Description.
On Error Resume Next causes execution to continue with the statement
immediately following the statement that caused the run-time error, or with
the statement immediately following the most recent call out of the
procedure containing the On Error Resume Next statement. This statement
allows execution to continue despite a run-time error. You can place the
error-handling routine where the error would occur, rather than transferring
control to another location within the procedure. An On Error Resume Next
statement becomes inactive when another procedure is called, so you should
execute an On Error Resume Next statement in each called routine if you want
inline error handling within that routine.
Note The On Error Resume Next construct may be preferable to On Error GoTo
when handling errors generated during access to other objects. Checking Err
after each interaction with an object removes ambiguity about which object
was accessed by the code. You can be sure which object placed the error code
in Err.Number, as well as which object originally generated the error (the
object specified in Err.Source).
On Error GoTo 0 disables error handling in the current procedure. It doesn't
specify line 0 as the start of the error-handling code, even if the
procedure contains a line numbered 0. Without an On Error GoTo 0 statement,
an error handler is automatically disabled when a procedure is exited.
To prevent error-handling code from running when no error has occurred,
place an Exit Sub, Exit Function, or Exit Property statement immediately
before the error-handling routine, as in the following fragment:
Sub InitializeMatrix(Var1, Var2, Var3, Var4)
On Error GoTo ErrorHandler
. . .
Exit Sub
ErrorHandler:
. . .
Resume Next
End Sub
Here, the error-handling code follows the Exit Sub statement and precedes
the End Sub statement to separate it from the procedure flow. Error-handling
code can be placed anywhere in a procedure.
Untrapped errors in objects are returned to the controlling application when
the object is running as an executable file. Within the development
environment, untrapped errors are only returned to the controlling
application if the proper options are set. See your host application's
documentation for a description of which options should be set during
debugging, how to set them, and whether the host can create classes.
If you create an object that accesses other objects, you should try to
handle errors passed back from them unhandled. If you cannot handle such
errors, map the error code in Err.Number to one of your own errors, and then
pass them back to the caller of your object. You should specify your error
by adding your error code to the vbObjectError constant. For example, if
your error code is 1052, assign it as follows:
Err.Number = vbObjectError + 1052
Note System errors during calls to Windows dynamic-link libraries (DLL) or
Macintosh code resources do not raise exceptions and cannot be trapped with
Visual Basic error trapping. When calling DLL functions, you should check
each return value for success or failure (according to the API
specifications), and in the event of a failure, check the value in the Err
object's LastDLLError property. LastDLLError always returns zero on the
Macintosh.
Mike F
