error handling techniques?

[Alan Grant Finlay]

In article <234 at smds.UUCP>, rh at smds.UUCP (Richard Harter) writes:
> 
> In our key product, which we assume is mission critical for our users,
> we take the strong view that any trapped error is a fatal error.  We try

This kind of approach involves either a purist conception about what is an
error or a library package which has such a narrow area of application that
applications using the package have highly predictable requirements.  

The problem for the supplier of a (practical) general purpose library package
is that what may be regarded an error by one application is not so regarded
by another.  An error such as "device not ready" for example could mean 
a fatal error (you forgot to buy the hardware) or a minor interuption (you
forgot to turn it on).  A classic example is what to do about a request to
perform an operation upon an object which doesn't exist.  For many systems
the appropriate action is to ignore the operation while for others it is a
fatal error.  One can always provide an additional procedure to check that the
object exists but this procedure may do a lot of work which has to be
repeated when the original operation is subsequently requested.   One way to
reduce the wasted effort is to save the work done by the check routine but
this is likely to be messy and appear complicated to users of the package.
The normal solution is to have some control about what happens when an
"error" occurs.

The subject line is "error handling techniques" and the original posting 
requested information about techniques for library packages.  For the reason
given above this is better called "exception handling techniques".  If you
want to get some insight into the difficulty of classifying errors/warnings/
exceptions have a look at the standard functions for the Icon programming
language.  Icon, which developed from Snobol, has expressions which can
evaluate properly or fail.  The language has control constructs such as
"repeat <exp>" which repeatedly evaluates the expression until it fails.
Most of the standard functions can fail but some also cause program termination
(i.e. an error).  The decision to classify exceptional circumstances as "fail"
or "error" is a difficult and somewhat arbitrary one (as admitted by Ralph 
Griswold, the author of Icon - sorry I don't have a reference for this
statement).

The best language for exception handling that I have come across is the
functional programming language ML.