Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!tut.cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden From: ogden@seal.cis.ohio-state.edu (William F Ogden) Newsgroups: comp.lang.modula3 Subject: Re: checked run-time errors and exceptions (was: running out of memory) Message-ID: <88308@tut.cis.ohio-state.edu> Date: 12 Feb 91 23:33:53 GMT References: <9102111557.AA02459@ibis.cs.umass.edu> <1991Feb11.152850.1851@src.dec.com> Sender: news@tut.cis.ohio-state.edu Reply-To: William F Ogden Organization: Ohio State University Computer and Information Science Lines: 21 Mick Jordan writes: > ... 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 ... A satisfactory abstract machine can't present the illusion of an infinite memory space when it can't sustain it. All computers are resource bounded, and accidentally running out of memory should be considered a programming error at some level. Invoking the NEW operator with inadequate remaining memory is violating its precondition just as surely as invoking the divide operator with a zero second argument is. The only difference is that while a prudent programmer can always prevent the problem with divide (by checking for a zero if he is unsure of his second argument), there is no general way to know when he is about to misuse NEW. Adding an exception mechanism doesn't solve the problem, because in many situations it is already too late to recover gracefully (or at all). Some additional condition of memory checking operation is needed if the language is going to provide adequate support for sound programming. /Bill