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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 759A6BC6C for ; Fri, 1 Feb 2008 17:04:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEDSokfAXQImh2dsb2JhbACQLwEBAQgKKZ1w X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="6823744" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 01 Feb 2008 17:04:28 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m11G4RbX025540 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 1 Feb 2008 17:04:28 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL7RokfC2fJbl2dsb2JhbACQLwEBAQEBBgQGCQgRB512 X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="8616728" Received: from anchor-post-33.mail.demon.net ([194.217.242.91]) by mail3-smtp-sop.national.inria.fr with ESMTP; 01 Feb 2008 17:04:27 +0100 Received: from orion.metastack.com ([80.177.38.218]) by anchor-post-33.mail.demon.net with esmtp (Exim 4.67) id 1JKyNN-000PGO-Ad for caml-list@inria.fr; Fri, 01 Feb 2008 16:04:25 +0000 Received: from countertenor (cpc1-cmbg6-0-0-cust264.cmbg.cable.ntl.com [81.101.137.9]) (authenticated bits=0) by orion.metastack.com (8.13.4/8.13.3) with ESMTP id m11FmVvv005224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 1 Feb 2008 15:48:32 GMT From: "David Allsopp" To: "'caml-list List'" References: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@mail.gmail.com><0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch><47A1D68B.70700@fmf.uni-lj.si><861w7xb0gi.fsf@Llea.celt.neu><89B95036-D3D1-41FD-B99A-ED46D54BF89E@erratique.ch><9d3ec8300802010250n5921415r36eb7f9773ef3681@mail.gmail.com> <2F3349DE-E200-4147-A5ED-78366A636D9E@erratique.ch> Subject: RE: [Caml-list] [OSR] Exceptionless error management Date: Fri, 1 Feb 2008 16:04:13 -0000 Organization: MetaStack Solutions Ltd. Message-ID: <003601c864ec$17fe2450$6c7ba8c0@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2F3349DE-E200-4147-A5ED-78366A636D9E@erratique.ch> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Achkw+HQZaHDyoFrRUyH3e0v/99O0QAG895A X-Scanned-By: MIMEDefang 2.63 on 172.16.28.218 X-Miltered: at discorde with ID 47A3430B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; programmer's:01 exn:01 compiler:01 ocaml:01 beginners':01 imho:01 unix:01 stack:01 stack:01 signatures:01 clearer:01 exception:01 exception:01 assert:01 caml-list:01 > > While I think having clearer signatures is great, I am still wary > > that this solution might prove too much of a constraint in some cases. > > I still think exceptions shouldn't be shunned so quickly. As their > > name clearly stipulates they should be used to handle exceptional > > cases, and sometimes the nature of what's an exceptional case is > > better left to the programmer's judgment (e.g. find). I believe that, > > when needed, both functions should be exposed in the interface (e.g. > > find and find_exn, or find and find_opt). > > I stand behind the one liner that will make the error implicit if you > want. Explicit first, implicit if you want to take the risk. > Personnally I wouldn't make it implicit unless it is for an "assert > false", but this is a matter of philosophy. Making the error explicit (i.e. using match) forces a decision on the client of a library - and that breaks the golden rule of library design because it's none of your business (as a library author) to force any decision on the end-user of your library that is not necessary to maintain correct operation of your library. > > Exceptions are an amazing tool to handle exceptional cases because > > they unwind stack the automatically. This means that you don't have > > to constantly thing about propagating the errors manually. > > I have nothing against exceptions per se. I also use them in my own > programs. But I don't want libraries to force me to use them. Recall > that the recommendation says nothing about client code. You can > perfectly define your own exceptions to propagate the error up. But your proposal forces me to *use* 'a option when I want to *ignore* exceptions. If I've got a map and, by proof, I know that I'll never do a find on it that would raise Not_found then I sure don't want to wrap every Map.find with either Option.get or a match clause. I heartily approve of the notion of exceptions for exceptional cases as a rule of thumb[*] - for example, many of the exceptions used in the Unix module "should" definitely be 'a option (you should never perform I/O without error checking, so 'a option - or, as I would use, ('a, 'b) result is appropriate). Furthermore, in the case of functions such as Map.find, the library author *cannot* know whether failure to find an item in the map is exceptional or not - and for that reason you cannot mandate 'a option as a return value - the only real solution is to provide both functions and allow the client to decide whether failure to find an item is exception or, failing that, provide the path with the easiest wrapping - and I'm afraid that's unarguably the exception route. Incidentally, there's no need to benchmark to discover whether 'a option wrapping is slower - it must be because it involves an extra allocation over using exceptions. However, this difference is probably not that great (and there are more possible compiler optimisations - though not necessarily exploited by OCaml - that become possible if you don't use exceptions). David [*] Although IMHO "exceptions for exceptional circumstances" is a bit of a beginners' mantra. Exceptions should be used in situations where you need to unwind the stack - exceptional circumstances are one instance of this. Another, equally valid, use of exceptions is in search algorithms - you may be several stack levels down before discovering that a certain branch decision was incorrect and using exception programming to unwind this is much neater than passing values around.