Re: Exception handling [ was Re: Zeroes and infinities ]

[David Hough 754R work <754r@xxxxxxxxxxx>]

Just to remind everybody about the 754R definition of throw exceptionName:



 "E.2 NON-RESUMABLE alternate exception handling modes
 NON-RESUMABLE-mode alternate exception handling attached to a block means: 
 handle the implied exceptions according to the non-resumable mode specified, 
then abandon execution of the block attached to and resume execution elsewhere 
as indicated. 
 Languages
 should define, and require implementations to provide, these non-resumable 
modes:

 -      throw exceptionName: causes an exceptionName not to be handled locally, 
but rather signaled to the next handling in scope, perhaps the function that 
invoked the current subprogram, according to the semantics of that language. 
 The invoker might handle
 exceptionName by default or by alternate handling such as signaling 
exceptionName to the next higher invoking subprogram.

 When a block is interrupted for non-resumable alternate exception handling, 
none, some, or all of the variables assigned in that block may be in an 
undefined state. 
 Some programming environments might choose to checkpoint all variables prior 
to executing
 the protected block, and then restore them prior to executing the alternate 
block; 
 others leave the responsibility to the programmer to decide which variables 
should be checkpointed prior to entry and then to explicitly restore them in 
the alternate block
 as needed."



I think that's exactly the right generalization of "terminate with message"
except that an outer level that has anticipated a particular message can
intercept it and do something else more appropriate at that outer level.     
But 754R does not require the ability
to resume execution in the place where it happened after throw exceptionName
and so it doesn't impose a big burden on implementations.
As the text emphasizes, results in interrupted calculations need not be
determinate or reproducible.

754R's RESUMABLE alternate exception handling modes are rather limited
and are spelled out in

 E.3 RESUMABLE alternate exception handling modes

Those modes do require hardware cooperation to get good performance
(and exception handling is all about performance) but can be implemented with
poor performance despite recalcitrant hardware.     Rather than global
defaults, they are intended to
be enabled in restricted contexts where they would make a difference in
performance with cooperative hardware.