Exception handling [ was Re: Zeroes and infinities ]

[Nick Maclaren <nmm1@xxxxxxxxxxxxx>]

David Hough 754R work <754r@xxxxxxxxxxx> wrote:
> That's all easy enough to understand in a traditional batch system
> with an operator at the console or at least a programmer to read the core
> dump later, but in general most programming languages don't embrace the
> notion of a console or a core dump, leaving that to the operating system...
> but in general, ...

Hang on.  That is so unfair that I assume you have misunderstood
something.  Almost all programming languages support the concepts
of (a) termination and (b) a diagnostic unit.  Fortran is actually
an exception, due to its history.  In particular, any program that
runs under a POSIX-compliant operating system necessarily has
access to those concepts.

To put it in POSIX terms, the handler would write an appropriate
message (preferably including a traceback) to stderr, close stderr,
and then call _exit with a suitable code.  I could describe the MVS
strategy, but it is similar.

I take your point that there ARE many important uses (process control
being one) where the concepts are close to unavailable, but I have
never claimed that "Terminate with message" is a universal solution.
It assuredly isn't.

What it is, is the ONLY solution that can be implemented on almost
all modern "general purpose" architectures and operating systems,
and a great deal of the reason for that is BECAUSE it is so limited.



> How is "Terminate with message" really different from "throw
> exceptionName" in annex E?  The only difference I can imagine is that
> "Terminate with message" is intended not to be interceptible at higher
> levels, which means that higher levels of programs that would be
> robust in the face of gratuitous intermediate exceptions must
> diligently guard against provoking such terminations, at great
> performance cost always, even if the exceptions are rare.  That's why
> termination is not the default.

Oh, gosh.  Hasn't anyone filled you in on THAT?  Surely there must
have been people with extensive run-time system experience on 754R?
Here is a simplified run-down of why throwing an exception is MUCH
harder than terminating with a message - the executive summary is
that trapping exceptions is easy; resuming after them isn't.

The first problem is that a fair amount of hardware didn't (and some
doesn't) flag exceptions synchronously, or with enough information to
determine where the error occurred.  Examples included the IBM 360/91,
370/195, Intel 8086/8087, most vector machines, Hitachi SR2201, the
DEC Alpha and many others that I had less contact with.

When the run-time system gets control, it hasn't got enough data to
determine in which block it should throw the exception!  That isn't
a theoretical problem, either, as I can witness from trying to code
it (though not for floating-point).  I rather assume that IEEE 754R
would like the exception thrown in the block where it occurred, and
not some randomly chosen block in the program.

A second, and related though different, one is that the handler may
not be given enough information on how to restore the environment
of the program, or enough power to do so.  That can be due to the
hardware, as on the 8086/8087, and is, in fact, WHY the C standard
forbids returning from a signal handler that traps SIGFPE.  But it
can also be due to the operating system treating the language run-
time system like a second class citizen.

A third problem, which is less fundamental but even more common, is
that it interferes with optimisation.  If the compiler reorders code,
it has to trap all exceptions, store them, and rethrow them at the
correct place.  And it clearly can't do that if it delays the execution
of code, so that is forbidden!

To a great extent, throwing an exception and passing control to a
label, catch block or whatever associated with the block in which the
exception occurs, brings in EXACTLY the same optimisation problems as
does updating global flags.  It adds a separate way of determining
execution sequence other than using the results.

A fourth problem, is that allowing that facility without defining what
the effects are on active data is not useful, and that can be VERY
hard to specify.  It isn't as simple as the draft implies, either.
for one thing, there are things like locks and states to consider,
but a much nastier one concerns read-only variables where the actual
implementation needs to modify them transparently and temporarily.
The words "might be changed" aren't always definable :-(

Oh, yes, that can all be done - but terminating with a message is
child's play compared with throwing an exception.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@xxxxxxxxx
Tel.:  +44 1223 334761    Fax:  +44 1223 334679