> 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