Important Notice

The pages on this site contain documentation for very old MS-DOS software, purely for historical purposes. If you're looking for up-to-date documentation, particularly for programming, you should not rely on the information found here, as it will be woefully out of date.

                                                 ◄Contents►  ◄Index►  ◄Back►
──────────────────────────────────────────────────────────────────────────────
 Using Error Handlers
 
 ■ The following sections discuss ways that Visual Basic uses error
   handlers:
   • At the module level
   • At the procedure level
   • At both module level and procedure levels
 
 Using Module-Level Error Handlers
 ■ Once enabled by the execution of an ON ERROR GOTO line statement, a
   module-level error handler stays enabled unless explicitly disabled by
   execution of an ON ERROR GOTO 0 statement somewhere in the module.
 
 ■ In a multiple-module program that contains only module-level error
   handlers, if an enabled error handler cannot be found in the module
   where the error occurred, Visual Basic searches back through the
   module-level code of all the calling modules, looking for an enabled,
   inactive error handler.
 
 ■ If an error occurs in a module-level error handler itself, Visual Basic
   does not automatically treat it as a fatal error. Visual Basic searches
   back through the module-level code of all the calling modules, looking
   for an enabled, inactive error handler.
 
 ■ If an ON ERROR GOTO 0 statement is encountered while the current module's
   module-level error handler is active, program execution is not
   automatically halted. Visual Basic searches back through the module-level
   code of all the calling modules, looking for an enabled, inactive error
   handler.
 
 Using Procedure-Level Error Handlers
 ■ SUB and FUNCTION procedures and DEF FN functions can contain their own
   error-handling routines.
 
 ■ To enable a local error handler, use the following statement:
 
         ON LOCAL ERROR GOTO line
 
   The argument line must be a label or line number in the same procedure as
   the ON LOCAL ERROR GOTO statement.
 
 ■ The local error handler is automatically disabled when the procedure
   returns, or by execution of the following statement:
 
         ON LOCAL ERROR GOTO 0
 
 ■ You may want program flow to avoid the statements that make up the error-
   handling routine. One way to keep the error-handling code from executing
   when there are no errors is to place an EXIT DEF, EXIT FUNCTION, or EXIT
   SUB statement immediately ahead of the error-handling routine.
   For example:
 
         SUB InitializeMatrix (var1, var2, var3, var4)
                .
                .
                .
             ON LOCAL ERROR GOTO ErrorHandler
                .
                .
                .
             EXIT SUB
             ErrorHandler:
                .
                .
                .
             RESUME NEXT
          END SUB
 
   The error-handling routine is located after the EXIT SUB statement and
   before the END SUB statement. This partitions the error-handling code from
   the normal execution flow of the procedure. However, error-handling code
   can be placed anywhere in a procedure.
 
 ■ In the VBDOS environment, or if you are compiling from the command line
   with the /O option:
   • If a local error handler is active and an END SUB, END FUNCTION,
     or END DEF statement is encountered, Visual Basic generates the run-
     time error message, "No RESUME."
   • If an EXIT SUB, EXIT FUNCTION, or EXIT DEF statement is encountered,
     Visual Basic does not generate a run-time error; it is assumed that
     this does not represent a logic error in the program.
 
 ■ In a multiple-module program that contains only procedure-level (local)
   error handlers, if an enabled and inactive error handler cannot be found
   in the procedure where the error occurred, Visual Basic searches back
   through all the calling procedures as well as the module-level code of all
   the calling modules, looking for an enabled, inactive error handler.
 
 Using Both Module-Level and Procedure-Level Error Handlers
 ■ For simplicity and clarity, avoid using both local- and procedure-level
   error handlers in the same program, except when using an error handler
   in the main module-level code is the only way to prevent a fatal error.
 
 ■ You can have both a module-level error handler and a local error handler
   enabled at the same time; both a local- and a module-level error handler
   can be enabled from within a procedure.
 
 ■ While searching for an enabled, inactive error handler, Visual Basic
   may encounter an active event handler. Unless an enabled error-handling
   routine is provided in the same module-level code as the event handler,
   Visual Basic generates a fatal error.
 
 ■ To produce Visual Basic code in modules that trap events, make sure an
   error handler is enabled in the same module-level code as the event
   handler at the time the event occurs.
 
 ■ Because event handlers can be located only at the module level, this is
   an exception to mixing module-level and procedure-level error handlers.
 
 ■ When an error-handling routine is finished and program execution resumes
   through a RESUME 0 or RESUME NEXT statement, the RESUME location is based
   on the location of the error-handling routine, not necessarily on the
   location where the error occurred. See: ◄RESUME Statement►