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 B3CA6BC0A for ; Sun, 10 Dec 2006 07:29:37 +0100 (CET) Received: from comtv.ru (comtv.ru [217.10.32.17]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBA6TbT1029539 for ; Sun, 10 Dec 2006 07:29:37 +0100 X-UCL: actv Received: from av1474.oops ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 10238540; Sun, 10 Dec 2006 09:29:41 +0300 Date: Sun, 10 Dec 2006 09:30:01 +0300 (MSK) From: malc X-X-Sender: malc@home.oyster.ru To: Brian Hurt Cc: caml-list Subject: Re: [Caml-list] Today's inflamatory opinion: exceptions are bad In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 457BA951.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; malc:01 ocaml:01 enforces:01 finalizer:01 ocaml:01 vale:98 wrote:01 exception:01 caml-list:01 functions:01 exceptions:01 exceptions:01 variant:02 snip:02 cleanup:03 On Sat, 9 Dec 2006, Brian Hurt wrote: > > I think I've come to the conclusion that exceptions are bad. > > In Ocaml, they're useless in many cases, and in most cases wrong. Avoiding > them generally makes for better code. There are two vague types of > exceptions- those the program can, and probably should- handle, and those > that the program can't, and probably should even try to, handle. > > 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. Which allow a > function to "pass along" an error if it wants to. So you could still write > functions like: [..snip..] Guess there's third type, code might detect catastrophic failure during the run of custom block finalizer, in which case, should there be a need for a cleanup actions, raising an exception might be the only choice, however i couldn't say offhand whether OCaml allows to raise exceptions in this context at all. -- vale