From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 68F76BC0A for ; Sun, 10 Dec 2006 19:28:50 +0100 (CET) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBAISnek021628 for ; Sun, 10 Dec 2006 19:28:50 +0100 Received: from [192.168.15.101] (ool-457da870.dyn.optonline.net [69.125.168.112]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JA200N08LZT4NQ0@mta1.srv.hcvlny.cv.net> for caml-list@inria.fr; Sun, 10 Dec 2006 13:28:42 -0500 (EST) Date: Sun, 10 Dec 2006 13:31:49 -0500 From: Serge Aleynikov Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad In-reply-to: <004501c71c40$b52e8d00$15b2a8c0@wiko> To: Andreas Rossberg , caml-list Message-id: <457C5295.3060001@hq.idt.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <004501c71c40$b52e8d00$15b2a8c0@wiko> User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) X-Miltered: at concorde with ID 457C51E1.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; rossberg:01 enforces:01 erlang:01 erlang:01 model:01 model:01 unhandled:01 stack:01 run-time:01 ocaml:01 run-time:01 uncaught:01 summarized:01 ocaml:01 fame:98 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. 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