Re: [Caml-list] Today's inflamatory opinion: exceptions are bad

[Jon Harrop <jon@ffconsultancy.com>]

On Sunday 10 December 2006 01:42, Brian Hurt wrote:
> I think I've come to the conclusion that exceptions are bad.

:-)

> For the former, returning a variant type ('a option if nothing else) is a
> better idea, for (at least) two reasons.  One, the type system enforces
> the requirement to actually handle the error, at the location the return
> value of the function is desired.

Being forced to handle errors immediately and then implement your own 
backtracking is not necessarily a good thing. In particular, it can make your 
code substantially more verbose, less clear and less efficient.

> Call this on a very long file, and you'll blow stack.  But if input_line
> returned, say, string option (where None meant end of file), the natural
> code would be:
> ...
> The work around to this is to basically implement the function:

It is often better to resort to imperative programming in that case:

  let list = ref [] in
  (try
     while true do
       list := input_line stdin :: !list
     done
   with End_of_file -> ());
  !list;;

> Note that this leaves the door open to sharing a single variant type among
> all the input functions:
>
> type 'a input =
>
>  	| Input of 'a
>  	| End_of_file
>  	| Read_error of string

I don't want to have to handle all exceptional circumstances at every step of 
the computation.

> There's one other use for exceptions I've seen (and done)- using them as
> non-local longjmps.  A classic example for this is a delete functions on a
> tree structure- you recurse all the way down to the leafs and discover
> that you're not deleting anything at all, what do you do?  I sometimes
> (too often) throw an exception to jump out of the recursion back up to the
> top level.

That is a productive optimisation in OCaml. The alternative would be to 
perform physical equality tests all the way back up the recursion just to 
avoid reallocating identical trees.

The same optimisations crops up all over the place. Rewrite systems can do the 
same thing to avoid rewriting identical expressions.

> Major changes to the language itself I see as unlikely in the near term.
> I'm mainly putting this rant out there to a) generate discussion, b) make
> people think, and c) maybe influence the design of future Ocaml libraries
> and code.

The F# language is related to OCaml and runs under .NET. With 
Microsoft's .NET, exceptions are very expensive. Consequently, there is an 
immediate problem converting OCaml code to F# code because it is likely to 
run very slowly if it uses functions like "find" and "assoc". However, I'm 
sure which I prefer. I am certainly used to OCaml's lightweight exceptions 
and use them all over the place.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists