[Cfp-interest] Background: How IEEE Exceptions Might have beenImplemented

[Mike Cowlishaw]

> There's a familiar conflict here, like that between static and dynamic
> rounding specifications.  If the programmer for a particular function
> feels that he has correctly and explicitly
> handled all possible instances of overflow, then
> he does not want that handling overwritten by a more global 
> abort-on-overflow specification inserted for debugging purposes.   
>
> On the other hand the
> programmer of the more global function may not agree that 
> overflow has been
> correctly handled and might want a convenient way to find out where it
> occurred without recompiling source code that he doesn't have 
> access to anyway.

This particular dilemma is perhaps best left to the 'debug environment' (IDE,
command line, etc.) which can dictate overriding of handling at lower levels.
It need not be a 'language' facility or option.

Separately -- I've just caught up on the pending 50+ posts here [I have been
away] and one thought occurred to me: perhaps the old PL/I "On Unit" would fit
the bill.  As a reminder, it looks a bit like this:

   On  <exception> then <statement>

e.g., 

   On underflow then call UnderflowHandler   /* Or GoTo, longjump, local code,
etc. */

These would usually be placed at the start of a program (hence a nod towards
single-pass compile) where they also give a warning to the reader of the program
that exceptions are possible, while not complicating the code below.  

Related and relevant is the SIGNALS phrase in Java or NetRexx which indicates
that this piece of code might signal some specified exception which is NOT
handled by the code and hence MUST be handled by the caller.

Mike