Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!pa.dec.com!src.dec.com!moss%ibis@cs.umass.edu
From: moss%ibis@cs.umass.edu (Eliot Moss)
Newsgroups: comp.lang.modula3
Subject: checked run-time errors and exceptions (was: running out of memory)
Message-ID: <9102111557.AA02459@ibis.cs.umass.edu>
Date: 11 Feb 91 15:57:44 GMT
Reply-To: moss@cs.umass.edu
Lines: 47
To: m3

>>>>> On 8 Feb 91 17:42:23 GMT, doug@snitor said:

doug> The preface to the Modula-3 report says:
doug>   "The goal of Modula-3 is to be as simple and safe as it can be
doug>    while meeting the needs of modern systems programmers."
doug> Modula-3 can't meet these goals until NEW has been redefined
doug> to raise an exception on memory exhaustion.

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.

Along these lines, CLU defined a number of specific exceptions for various
situations, including "bounds", "end_of_file", and the like, and had a
(slightly special) exception called "failure" for indicating that the
underlying support abstraction(s) had failed. Running out of storage was one
failure situation; accessing an uninitialized variable was (supposed to be)
another (not fully implemented to my knowledge, but more modern compiler
technology makes it easier); de-referencing a NIL pointer is a good example in
Modula-3.

A robust program could be built that would ty to clean up as much as possible
from a failure exception and abort or skip the particular task it was working
on at the time, perhaps logging the failure for maintainers (though log
overflow should also be considered!). Such a program needs to be a bit
intelligent about whether an error is recoverable (and the action should be
restarted) or not (in which case the action should *not* be restarted, to
avoid an infinite loop; at the very least, the actio should be deferred if at
all possible). This means that the exceptions need to be standardized enough
for programs to be able to tell the difference.

All of this needs to be standardized as much as possible, for portability,
though there are bound to be OS-, compiler-, and application-specific things
that cannot be dealt with in the language definition.

		J. Eliot B. Moss, Assistant Professor
		Department of Computer and Information Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu