Reviewed and Revised May 2024
According to received wisdom, error handling is one of the two most challenging issues in programming. Along with naming things. (And off-by-one errors.)
When an error (aka "exception") occurs while processing an ASB statement, two things happen:
| • | The error number and location are saved in internal variables that can be queried via the ERR() function. |
| • | The flow of control is interrupted and redirected to either the default error handler, or an explicitly defined trap label. |
| • | If the TRACE System Parameter BASERR option is enabled, as it normally should be, details about the error, including the stack trace, are written to the ashlog.log file. |
This is the ASB version of the "try / catch" framework for error handling used by some other languages.
Default Error Trapping
If no explicit error trapping has been declared in the current context, the default error handler does one of the following, depending on that context:
If within a User-Defined Function, an implicit EXITFUNCTION is executed, terminating the function and forwarding the error back to the caller, where it appears as if the error had occurred on the statement calling the function. Note that this handler applies whether or not the function is within a main program or an SBX subroutine.
If not within a function (i.e if in the main routine), an implicit END is executed. In the case of an SBX Subroutine, control returns to the program that called it, with the error status cleared. Otherwise, it displays an error message of the following form and then drops to the Command Prompt with the error condition cleared.
?<error description> {in line #} at location counter &hxxxx of <program name>
The error description is extracted from the SYS:ERRMSG.xxx file (xxx is the current language extension, e.g. "USA") based on the error number. The line number clause appears only if the program has line numbers. The location counter always appears; it can be cross-referenced to the source code using the compiler List File.
Explicit (Application Controlled) Error Trapping
To exercise greater control, you can declare your own error handlers, using the ON ERROR GOTO statement, which see for details.
Comments
Note that all of the discussion above refers only to a particular class of errors that occur within and interrupt ASB statements. Many internal (non-SBX) Xcall subroutines and even system functions may explicitly detect other classes of errors, returning them as status (aka error) codes. Those kinds of errors are not affected by the error trapping described in this topic.
See Also
