Error Handling/Reporting Cycle
The warning system was designed to work in conjunction with several layers of CALLed programs. If an error occurs in a program that was CALLed by another program, the program with the error should call _warn.utl with an initial indication of an error. It should then exit with an error status, causing a trap to the error routine of the program that called it. For example, consider the following programs A, B, and C:
|
Assume that the user RUNs program A. Program A CALLs program B, which CALLs program C. Program C generates an !ERROR=41, causing control to go to the Program C error routine. Because !ERROR=41, the program should call the _unerr.utl utility, loading the warning buffer with the following:
|
|
Program C adds an additional line to the warning buffer:
|
Program C then exits to program B with an error condition. Typically, this is EXIT 200. Program B executes its error handler and adds a line to the warning buffer:
|
Next, program B exits to program A with an error condition, EXIT 200, and Program A invokes its error routine creating the following warning buffer:
|
This is displayed on the screen because Program A calls _saywarn.utl.
The warning message shows exactly why the application failed: Program B had a failure because Program C had a failure. From top to bottom, the error message gets more specific about the actual cause of the failure.