caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Serge Aleynikov <serge@hq.idt.net>
To: Andreas Rossberg <AndreasRossberg@web.de>,
	caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad
Date: Sun, 10 Dec 2006 13:31:49 -0500	[thread overview]
Message-ID: <457C5295.3060001@hq.idt.net> (raw)
In-Reply-To: <004501c71c40$b52e8d00$15b2a8c0@wiko>

Andreas Rossberg wrote:
> "Brian Hurt" <bhurt@spnz.org> 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.

http://www.erlang.se/doc/programming_rules.shtml#REF42466

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):

http://www.erlang.org/pipermail/erlang-questions/2006-November/023983.html

Regards,

Serge


      parent reply	other threads:[~2006-12-10 18:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-10  1:42 Brian Hurt
2006-12-10  2:40 ` [Caml-list] " skaller
2006-12-10  2:51 ` Martin Jambon
2006-12-10  3:35 ` Chris King
2006-12-10  6:32   ` Jon Harrop
2006-12-10 19:07     ` brogoff
2006-12-10 18:04   ` Richard Jones
2006-12-10 23:27     ` Chris King
2006-12-11 15:55       ` Richard Jones
2006-12-15 11:13         ` Frédéric Gava
2006-12-11 17:28     ` Mike Lin
2006-12-11 20:09       ` Richard Jones
2006-12-11 23:38   ` Olivier Andrieu
     [not found]   ` <C841DA73-83D4-4CDD-BF4A-EA803C6D6A08@vub.ac.be>
2006-12-23  4:23     ` Ocaml checked exceptions Chris King
2006-12-10  6:30 ` [Caml-list] Today's inflamatory opinion: exceptions are bad malc
2006-12-10  6:36   ` malc
2006-12-10  6:56 ` Jon Harrop
2006-12-10  9:51 ` Andreas Rossberg
2006-12-10 11:00   ` Tom
2006-12-10 11:25     ` Andreas Rossberg
2006-12-10 13:27   ` Jean-Christophe Filliatre
2006-12-10 19:15     ` Haoyang Wang
2006-12-10 21:43       ` Jean-Christophe Filliatre
2006-12-11 13:10       ` Diego Olivier FERNANDEZ PONS
2006-12-10 18:31   ` Serge Aleynikov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=457C5295.3060001@hq.idt.net \
    --to=serge@hq.idt.net \
    --cc=AndreasRossberg@web.de \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).