EXALT has a statement, the UPON statement, that allows the programmer to specify what action is to be taken in the event of an error or an unusual condition in the program.
It has the form
UPON condition,alternative
where condition is a character expression naming a condition that will cause the alternative to be executed.
alternative may be any of the possibilities provided for the IF statement. If the alternative is not an unsigned statement number, or, if a sequence, if that sequence does not result in a branch out to the main program, return is made to the place where the exception ocurred, not the statement following the UPON statement.
Thus, UPON condition,* means that the condition is to be ignored.
In addition, UPON condition,0 indicates that the pre-existing default action is to be taken as the result of the condition, and UPON condition,! indicates that the condition is to be considered an error, and reported according to the default EXALT execution-time error reporting mechanisms even if that condition is not normally one considered an error.
Clauses such as END= in an input/output statement, or FLU= at the end of an assignment statement, override an UPON condition currently in effect.
The UPON statement is an executable statement. If it is executed within a subprogram, the condition ceases to apply when return from that subprogram is made.
The UPON condition, however, applies to all subroutines called by the program in which it appears, even predefined subroutines, with some exceptions possible as a result of operating system protection measures. Also, the subprograms may contain UPON statements referring to the same condition, which would temporarily override the response previously set. This also does not apply if the called subroutine is, or could be, executing in parallel to its caller; in this case, it must have its own UPON statement if response to a given condition is required (*,0, and ! alternatives only are retained under that circumstance).
As the UPON statement is an executable statement, it can only affect that portion of a program's performance that is determined at execution time. Thus, a statement such as
UPON 'SUBSCRIPTRANGE',!
will have no effect unless the compiler has been instructed to generate code in which an array bounds overflow is somehow tested for. The statement
UPON 'FIXEDOVERFLOW',!
has no such problem on architectures where a fixed-point overflow generates a (usually disabled) interrupt, as it is then possible to enable that interrupt (or request that the operating system do so) and request the operating system to transfer control to a given point in the program (for an alternative other than !).
On other computers, however, nothing happens in response to a fixed-point overflow unless explicit tests are inserted into code; then, this would not be the default.
Available conditions and their default responses are implementation dependent.