Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: caml-list@inria.fr
Subject: Re: small code problem
Date: Fri, 9 Jul 1999 15:56:31 +0200	[thread overview]
Message-ID: <99070915534909.28040@schneemann> (raw)
In-Reply-To: <199907090927.KAA09195@toy.william.bogus>

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
abstract.

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
--
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------




       reply	other threads:[~1999-07-10 18:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <199907090927.KAA09195@toy.william.bogus>
1999-07-09 13:56 ` Gerd Stolpmann [this message]
1999-07-11 19:23   ` Markus Mottl
1999-07-08 18:23 Damien Doligez
  -- strict thread matches above, loose matches on Subject: below --
1999-07-02 22:30 <Brad Knotwell
1999-07-08  4:56 ` Markus Mottl
1999-07-08 22:49 ` Gerd Stolpmann
1999-07-09  0:27   ` <Brad Knotwell
1999-07-09  1:37     ` Fabrice Le Fessant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99070915534909.28040@schneemann \
    --to=gerd.stolpmann@darmstadt.netsurf.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox