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.9 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 97287BC6C for ; Fri, 1 Feb 2008 12:31:55 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIeRokfAXQImh2dsb2JhbACQJAEBAQgKKZcXhho X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="7510651" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 01 Feb 2008 12:31:55 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m11BVrST014295 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 1 Feb 2008 12:31:55 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAECSokfRVZK1emdsb2JhbACQJAEBCQgplxqGGg X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="22052164" Received: from wa-out-1112.google.com ([209.85.146.181]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Feb 2008 12:31:54 +0100 Received: by wa-out-1112.google.com with SMTP id m34so561704wag.9 for ; Fri, 01 Feb 2008 03:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=cmgvrqjrpmdimluQFypXAnzK4sg0zk/AHDADtEgMhYE=; b=TYOsh8tdJNNA4pqA/7eTI16s9dkSob6emE0PXMfY3CQjY6njuQGtuPFkaMYBV0i4ogrFMwYqYwlNsIIx/9JNe/P2A/LebRtOMh8dSQ4b0NVnPU2AU6KTmnGCpi6hlptMzPrbM+ZSwEozrG9A7NEmEzTbOMV9MdVmlcTDZwOAR/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=eOTWdbNrYe4RF20DJ2DD8msd3HwoA70Vk944CZNRjjNcQNhFksXtvZmDqe+5ZN6zoMNc3Ikh2RhGszR5wvtjsrVu0xf97eTrbFF7+5BbCQ5+q4UxZrUz88YwwuEyaHpA28j0/laNeUEjK3ocdH07usbi+l9ILty4lG2kB8+bcmA= Received: by 10.114.195.19 with SMTP id s19mr3881994waf.57.1201865511912; Fri, 01 Feb 2008 03:31:51 -0800 (PST) Received: from ?192.168.1.58? ( [85.0.108.124]) by mx.google.com with ESMTPS id f6sm527495nfh.21.2008.02.01.03.31.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Feb 2008 03:31:51 -0800 (PST) Message-Id: <2F3349DE-E200-4147-A5ED-78366A636D9E@erratique.ch> From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: caml-list List In-Reply-To: <9d3ec8300802010250n5921415r36eb7f9773ef3681@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] [OSR] Exceptionless error management Date: Fri, 1 Feb 2008 12:31:52 +0100 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> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at discorde with ID 47A30329.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 programmer's:01 exn:01 haskell:01 idioms:01 trivial:01 variants:01 50,:98 polymorphic:01 stack:01 signatures:01 clearer:01 clearer:01 assert:01 Le 1 f=E9vr. 08 =E0 11:50, Till Varoquaux a =E9crit : > 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 =20= want. Explicit first, implicit if you want to take the risk. =20 Personnally I wouldn't make it implicit unless it is for an "assert =20 false", but this is a matter of philosophy. > 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 =20 programs. But I don't want libraries to force me to use them. Recall =20 that the recommendation says nothing about client code. You can =20 perfectly define your own exceptions to propagate the error up. > I am also not very enthused by the use of the polymorphic variant > versus a Haskell like [Left | Right] variant. I think the former can > lead to hard to track errors (excerpt from the manual: "Beware also > that some idioms make trivial errors very hard to find.") bringing an > illusion of safety rather than safety itself. The latter also > separates in clearer way the error cases from the success cases. On the safety bit I think this is less true if you actually take care =20= to close your variants. However I tend to agree on the clearer =20 separation of cases. I added a request for comments on this at the end =20= of the OSR page to standardize on [ `Value of ... | `Error of ... ] =20 instead of [ `Value of ... | .... ]. Best, Daniel