Project 54: Exception Handling 

A ducument by Tom Hull was published 1988.

---------------------------------------------------------------

Pasadena 1984:
==============

Hull considers only overflow o, underflow u, indeterminate i, 
zerodivide z, and fail f.

He views such exceptions as being raised by operators: arithmetic 
operators, closely related operators such as mod and setexp, elementary 
functions, and user-defined functions and procedures. (For user 
defined functions and procedures to be able to raise exceptions, the 
user must be able to cause such returns to be made: any of the 5 
from a function, but only fail from a procedure).


Then, if an exception arises, the user should be able to specify 
what action is to be taken. The user should be able to specify the
substitution of a value in place of the "exception" value before 
the calculations are resumed, as well as any other sequence of 
instructions (such as setting a flag, or printing a message). 
Alternatively, returning an exception is a possibility that would 
be useful, as would the opportunity to abandon the calculation at
the point where the exception arose in order to try some other 
approach.

If no provision for handling the exception is made by the user, a 
default system action should be taken such as stop with message.
Otherwise three ways for providing a handler are suggested

(i) Targeted handlers are of the form:
     	@ exIds : body [, exIds : body]@
     	placed after the operation which raises the exception(s)
     	identified (exIds).

(ii) Untargetted handlers are of the form:
	handler
	|exIds : body [, exIds : body]
	end handler
	whose the scope is what is visible in the block in which 
	the handler is declared.

(iii) A general handler is of the form :
	otherhandler
	|exIds : body [, exIds : body] 
	end otherhandler

where the scope includes every thing within the block in which 
it is declared, and not just what is visible.

No substitution is allowed for a failure exception raised by a
procedure. No substitution under any circumstances is allowed
in an otherhandler.

Exceptions in handlers are considered to be within the scope of 
handlers at a higher level, so that handlers are not recursive.

There is a discussion between Hull, Gentleman, Reid, Cody, Smith about
what the IEEE standards report allows and what Hull requires, which is
more abstract. Next there is a discussion between Einarsson Vouk,
Smith, Reid about exception handling in Fortran 8x. Reid has sent
documents to Hull, Ford. Vouk would like them too. Reid and Smith need
advise for the Fortran Committee: the European mechanism is very
general, the second mechanism focuses on arithmetic. Vouk, Gentleman
volunteer to read the document.

Stanford 1988:
==============

T. Hull talked about a more general, and very current issue, of
attaching of exception handlers to operators. This approach extends
the definition of an operator. A detailed description of the technique
will appear as a TOMS paper (see below). It was noted that in some
instances problems may arise with concurrency because of communication
overheads (busy-wait).

Beijing 1988:
=============

Document:	T. Hull.

The draft paper presented by Hull at the previous meeting was
published in ACM TOMS (see below). Exception handling in the C
language was briefly discussed (Hanson, Vouk, Fosdick).

Jerusalem 1990:
===============

Hull suggested merging [44] and [54] with [63] (Vouk). Accepted.
Project [54] closed.

Documents:
==========

T. E. Hull, M. S. Cohen, J. T. M. Sawshuk, and D. B. Wortman:
"Exception handling in scientific computing"
ACM Transactions on Mathematical Software (TOMS),
Volume 14, Issue 3  (September 1988), pp 201 - 217.