|Is multi-level function return possible? firstname.lastname@example.org (noitalmost) (2014-03-10)|
|Re: Is multi-level function return possible? email@example.com (George Neuner) (2014-03-11)|
|Re: Is multi-level function return possible? firstname.lastname@example.org (2014-03-26)|
|Re: catch and throw, was Is multi-level function return possible? email@example.com (2014-03-27)|
|Re: catch and throw, was Is multi-level function return possible? firstname.lastname@example.org (Bakul Shah) (2014-03-26)|
|Re: exception catching in PL/I email@example.com (Robin Vowels) (2014-03-28)|
|Re: exception catching in PL/I firstname.lastname@example.org (Martin Ward) (2014-04-16)|
|From:||"Robin Vowels" <email@example.com>|
|Date:||Fri, 28 Mar 2014 10:50:43 +1100|
|References:||14-03-020 14-03-023 14-03-065 14-03-068 14-03-070|
|Posted-Date:||27 Mar 2014 20:16:57 EDT|
From: "Bakul Shah" <firstname.lastname@example.org>
Sent: Thursday, March 27, 2014 5:20 PM
> PL/I had ON and SIGNAL statements. SIGNAL would signal an exception.
> ON would catch it. REVERT to cancel the effect of ON. Web search
> indicates it was defined in 1964 but implemented later. May be the
> PL/I designered borrowed it from an earlier language/facility?
PL/I provided the means to catch an exception, typically a hardware exception,
but not limited to them.
S/360 hardware exceptions included floating-point underflow, floating-point overflow,
division by zero, fixed-point overflow, and invalid decimal arithmetic.
A few of these exceptions could be turned on and off at the program level
(e.g., float underflow). Others such as an invalid decimal data interrupt could not be turned
off, and were taken by the operating system which in turn passed control to the
program's error handler.
Thus, the hardware exceptions implemented in PL/I were OVERFLOW, UNDERFLOW,
FIXEDOVERFLOW, ZERODIVIDE, and invalid decimal data.
Those implemented in software included CONVERSION, SUBSCRIPTRANGE,
STRINGRANGE, ENDPAGE, ENDFILE.
The user could introduce his own named conditions, and invoke them using a SIGNAL
ON statements established the action to be taken in the event of an exception.
SIGNAL statements were provided for testing purposes (so that you could check out
your exception-handler), and for invoking a user-defined condition.
Certain exceptions can be turned on and off at procedure level and at
statement level; hence the statement prefixes such as NOFIXEDOVERFLOW
and FIXEDOVERFLOW. Other exceptions such as ENDPAGE cannot be turned
off, but the exception handler can be a user-written null operation.
Return to the
Search the comp.compilers archives again.