Re: small code problem

From: Gerd Stolpmann (
Date: Fri Jul 09 1999 - 15:56:31 MET DST

From: Gerd Stolpmann <>
Subject: Re: small code problem
Date: Fri, 9 Jul 1999 15:56:31 +0200
Message-Id: <99070915534909.28040@schneemann>

On Fri, 09 Jul 1999, William Chesters wrote:
>Gerd Stolpmann writes:
> > It is almost always a bad idea to trap Invalid_argument,
> > Out_of_memory, Stack_overflow, and Division_by_zero, as these
> > exceptions are thought as last resort that indicates a bad system
> > state that must not happen but happened.
>That may be a bit misleading---it's not in any sense "dangerous" to
>continue after Invalid_argument or Division_by_zero. Whether you
>check arguments before passing them in, or whether you catch the
>exceptions that may get thrown if you don't, is a matter of what seems
>more stylish/appropriate in context. (For instance, sometimes one is
>more efficient, sometimes the other.)

Right, it is not dangerous. But I disagree that it is only a matter of
"style" not to catch these exceptions. Let me explain this a bit more

Programming can be seen as a transformation of conditions. For example:

        if Array.length Sys.argv >= 1 then do_this else do_that

You can reason about this statement, and you come to the (trivial) result that
the length of the array is >= 1 just before 'do_this' is evaluated. Because
of this, 'do_this' can be something like 'Sys.argv.(0)', and evaluation is
always successful. It is important to consider this as a kind of reasoning
which is done by the programmer and which might be errorneous (it is often not
so trivial). Of course, the interpreter checks again that the array is big
enough, but I would prefer another view: Not the array size is checked, but
what the programmer thinks about the array size. This has the advantage that
Invalid_argument is an indicator that I came to the wrong conclusions when I
wrote the program. -- In the literature this is known as "defensive
programming", it often leads to much more stable programs.

>I would worry about continuing after a Stack_overflow, but I suspect
>Out_of_memory is also pretty much safe.

Stack_overflow often indicates infinite recursions, and sometimes that
the elimination of tail recursions did not work. The stack has normally
been cleaned up after that, and it should be no problem to continue, for example
because you want to save data before exiting. Out_of_memory is more serious,
because memory continues to be tight which can lead to infinite loops. I
recommend to have at least a counter, and if this exception occurs several
times, exit the program immediately.


Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail: (privat)

This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:23 MET