Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!deccrl!news.crl.dec.com!shlump.nac.dec.com!rust.zso.dec.com!pa.dec.com!src.dec.com!Marc Wachowitz <I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU>
From: I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU (Marc Wachowitz)
Newsgroups: comp.lang.modula3
Subject: NEW out of memory
Message-ID: <9102131002.AA01768@decpa.pa.dec.com>
Date: 12 Feb 91 15:49:01 GMT
Lines: 25
To: m3

There were several articles proposing various schemes how to deal with
NEW running out of memory. Most of them only considered "polite abortion"
of the program. I think it has to be possible to control the effect of
every single invocation of NEW; sometimes an application may be able just
to ignore the failure of a (in these cases usually large) allocation
attempt. Termination handlers are no serious help in this case.

For the benefit of existing & innocent programs, one might let the
current behavious of NEW unchanged (but extend the language definition
to define failure as a checked runtime error, which may be reported in
an implemenation-dependent way).

A new procedure (say TRYNEW) would be defined to be equivalent to NEW,
except that it raises an exception (say NEWFAILURE) on failure.

This exception should not be implicitly included in raises clauses,
but should for convenience be directly visible (instead of needing to be
imported from some interface) in every scope (i.e. be a predefined name).

Considering the proposed features to install termination: I do strongly
suggest that at least a simple variant be made part of the language spec.
It should at least allow each module to register one procedure, which
may then take care of data managed by the module (e.g. keeping a list of
opened files and closing them on exit; I prefer that over the current
scheme of auto-flushing writers).