Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Today's inflamatory opinion: exceptions are bad
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-12-10 (18:28)
From: Serge Aleynikov <serge@h...>
Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad
Andreas Rossberg wrote:
> "Brian Hurt" <> wrote:
>> 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.  Want the result?  Handle 
>> the errors.
> I guess Joe Armstrong (of Erlang fame) would have to say a lot about how 
> to deal with failure properly. According to him, and the seemingly 
> successful Erlang philosophy (which is, "let it crash"), attempts to 
> locally handle errors are exactly the wrong approach. See his very 
> insightful thesis.

This philosophy indeed works quite well in case of Erlang because of its 
good error isolation and concurrency model.

In that model the worse that can happen to a faulty code is that an 
unhandled exception can crash a light-weight process running that code 
inside a virtual machine.  The death of such a process would be detected 
by a supervising process that would take care of error logging by 
providing essential details about the exception (such as stack frames, 
location and reason of the original fault), and restarting the offending 
process per its configuration spec.

This approach requires very tight cooperation between the run-time 
system and the user process causing a fault.  Since OCaml/C++/Java/etc 
languages don't have native support of concurrency at the language level 
(i.e. rely of the OS for that) this makes it quite difficult to follow 
the "let it crash" philosophy.  The only option in their run-time 
environment for handling uncaught exceptions is to signal OS of an 
abnormal exit, and let the OS do the process cleanup with minimal crash 
information being available at that level.

Brian Hurt wrote:
 > I think I've come to the conclusion that exceptions are bad.

In programming large systems, a very useful rule that I find applicable 
to the subject is summarized here (this thread originated from a very 
similar argument of exceptions vs. tagged tuples, or variant types in 
case of OCaml):