From: Markus Mottl <mottl@miss.wu-wien.ac.at>
Message-Id: <199907111823.UAA14351@miss.wu-wien.ac.at>
Subject: Re: small code problem
To: Gerd.Stolpmann@darmstadt.netsurf.de
Date: Sun, 11 Jul 1999 20:23:46 +0100 (MET DST)
In-Reply-To: <99070915534909.28040@schneemann> from "Gerd Stolpmann" at Jul 9, 99 03:56:31 pm
> 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 also think that checking conditions by catching exceptions leads to a
wrong style of programming: if you catch such exceptions around somewhat
bigger blocks, you might catch one which was raised in a completely
different context than you had imagined. But your program would continue
as if everything were ok, possibly leading to misbehaviour in a program
part far away from the point where the exception was raised/caught. Using
explicit checks before evaluation of "dangerous" expressions is much
safer and more transparent.
Best regards,
Markus
-- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:23 MET