From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA05291 for caml-redistribution; Mon, 12 Jul 1999 20:26:54 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA16453 for ; Sun, 11 Jul 1999 20:23:58 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id UAA07849 for ; Sun, 11 Jul 1999 20:23:57 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id UAA14351; Sun, 11 Jul 1999 20:23:46 +0200 (MET DST) From: Markus Mottl 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) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <99070915534909.28040@schneemann> from "Gerd Stolpmann" at Jul 9, 99 03:56:31 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis > 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