Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!ira.uka.de!rusmv1!ifistg!bs3!schoebel
From: schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel)
Newsgroups: comp.lang.modula3
Subject: Re: checked run-time errors and exceptions (was: running out of memory)
Message-ID: <7896@ifi.informatik.uni-stuttgart.de>
Date: 13 Feb 91 09:00:37 GMT
References: <9102111557.AA02459@ibis.cs.umass.edu> <1991Feb11.152850.1851@src.dec.com>
Sender: news@ifistg.uucp
Organization: Informatik, Uni Stuttgart, W. Germany
Lines: 24

In article <1991Feb11.152850.1851@src.dec.com> mjordan@src.dec.com (Mick Jordan) writes:

>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

I don't agree with this failure of the abstract machine. There are cases
when a programmer wants to use all *available* memory, e.g. when
implementing a cache. Such a program will run with less cache memory also.
The really amount of memory is runtime dependant, but *not* the
semantics of the program.

From a general purpose language I will expect to support me with
information about available ressorces, allowing to make runtime
decicions about ressource managing strategies.

Thomas Schoebel

E-mail: schoebel@ifi.informatik.uni-stuttgart.de
Phone:  +49 711 121-1409