Error Handlers The Basic Control Engine supports nested error handlers. When an error occurs within a subroutine, the Basic Control Engine checks for an On Error handler within the currently executing subroutine or function. An error handler is defined as follows: Sub foo() catch: Error handlers have a life local to the procedure in which they are defined. The error is reset when (1) another On Error statement is encountered, (2) an error occurs, or (3) the procedure returns. |
Cascading Errors If a runtime error occurs and no On Error handler is defined within the currently executing procedure, then the Basic Control Engine returns to the calling procedure and executes the error handler there. This process repeats until a procedure is found that contains an error handler or until there are no more procedures. If an error is not trapped or if an error occurs within the error handler, then the Basic Control Engine displays an error message, halting execution of the script. Once an error handler has control, it must address the condition that caused the error and resume execution with the Resume statement. This statement resets the error handler, transferring execution to an appropriate place within the current procedure. An error is displayed if a procedure exits without first executing Resume or Exit. |
Visual Basic Compatibility Where possible, the Basic Control Engine has the same error numbers and error messages as Visual Basic. This is useful for porting scripts between environments. Handling errors in the Basic Control Engine involves querying the error number or error text using the Error$ or Err function. Since this is the only way to handle errors in the Basic Control Engine, compatibility with Visual Basic's error numbers and messages is essential. |
Errors fall into three categories:
|
You can intercept trappable errors using the Basic Control Engine's On Error construct. Almost all errors in the Basic Control Engine are trappable except for various system errors. |
E |