Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!src.dec.com!mjordan
From: mjordan@src.dec.com (Mick Jordan)
Newsgroups: comp.lang.modula3
Subject: Re: checked run-time errors and exceptions (was: running out of memory)
Message-ID: <1991Feb11.152850.1851@src.dec.com>
Date: 11 Feb 91 23:28:50 GMT
References: <9102111557.AA02459@ibis.cs.umass.edu>
Sender: news@src.dec.com (News)
Reply-To: mjordan@src.dec.com (Mick Jordan)
Organization: DEC Systems Research Center
Lines: 33

In article <9102111557.AA02459@ibis.cs.umass.edu>, moss%ibis@cs.umass.edu (Eliot Moss) writes:

> I tend to agree with this, and NEW is not the only problem. I think the
> language committee should revisit the issue of checked run-time errors versus
> exceptions with an eye to supporting the construction of very robust programs:
> ones that attempt to handle errors on their own and continue operation.
> Running out of storage in NEW is an obvious case, but there are undoubtedly
> others. I would tend to argue that even though accessing beyond the bounds of
> an array is an error (i.e., should never happen in a properly coded program),
> it may still be reasonable for a robust program to attempt to recover from
> bugs in some of its routines.
> 

If my memory is correct, two committee members including myself, argued strongly
for checked run-time errors to be mapped in the "fail" exception, which would
be implicitly included in every RAISES clauses. This is the situation in
Modula-2+, which even names this exception as FAIL. On can catch FAIL with
an ELSE handler which, when used with restraint, provides adequate
last ditch bullet-proofing. The argument against boils down to implementation
difficulties in mapping some hardware failures (efficiently) into exceptions.
(Having said that, the Olivetti implementation did map failures into an 
exception, which could be caught by ELSE. We used this to good effect in
one program which, when it crashed, would bring down the entire OS).

However, I have a strong dislike for naming individual failure exceptions and,
therefore, encouraging, for example, code which catches NIL faults. There is 
something very bizarre about explicitly catching what are truly programming
errors. Although running out of memory is not a programming error, it is
effectively a failure of the Modula-3 abstract machine, and I am curious to
know how you can write portable code to recover from it, given that you must
be very careful not to call any code which might call NEW again.

Mick Jordan