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=1.1 required=5.0 tests=AWL,HTML_MESSAGE,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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 1A3B5BC6B for ; Wed, 24 Oct 2007 13:05:11 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAE7DHkfRVca+kmdsb2JhbACCPTWLZwEBAQEHAgYTFoEp X-IronPort-AV: E=Sophos;i="4.21,323,1188770400"; d="scan'208";a="18551693" Received: from rv-out-0910.google.com ([209.85.198.190]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2007 13:05:09 +0200 Received: by rv-out-0910.google.com with SMTP id k20so133717rvb for ; Wed, 24 Oct 2007 04:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=ibqAV2HD1WV0UsQv1YzUFppKUIVaRv1u/Jf5Came1wI=; b=Goi6ZyLe6Cq4P0Cee+xW28/AZEnBJIzN5ot76zEFnP9iNXOXNKSZ0myxPZIPcgBTGlJMqwOLM4xA3WlFWFi+ttBpHKgcmzmvWvCxe5MddNHtgOAKklkIUTgnhzETah9c7vPYwtL1cgbhC45pLQYEtVMMlo/VOHpTFTzP3nx6Pmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=kxeLYQoaawrpotpga3OBOElVp6o6SOwsx0YdLT15GH4j8wSxoHiosI07fgP8QTTUfb6NeemRcZBkdgfHPAHnCeIllz9V8q6w8TBjSYnKmknevkY0G+9X2PGjIlTAI6iLeaXAe9SLumz40pHTSB9x/K6b0VhB9VQow6hG9G10OXg= Received: by 10.140.133.10 with SMTP id g10mr189650rvd.1193223908478; Wed, 24 Oct 2007 04:05:08 -0700 (PDT) Received: by 10.141.99.5 with HTTP; Wed, 24 Oct 2007 04:05:08 -0700 (PDT) Message-ID: <891bd3390710240405l40ddee68l1d8876c7be98ff34@mail.gmail.com> Date: Wed, 24 Oct 2007 07:05:08 -0400 From: "Yaron Minsky" Sender: yminsky@gmail.com To: "Xavier Leroy" Subject: Re: [Caml-list] Preferred use of Invalid_argument and Failure Cc: "=?ISO-8859-1?Q?Micha=EBl_Le_Barbier?=" , caml-list@yquem.inria.fr In-Reply-To: <471EFD20.5010303@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3433_16852063.1193223908464" References: <867ildqacq.fsf@Llea.celt.neu> <471EFD20.5010303@inria.fr> X-Google-Sender-Auth: 2f69c4add47bb3d6 X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 variants:01 variants:01 polymorphic:01 polymorphic:01 wrote:01 wrote:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 ------=_Part_3433_16852063.1193223908464 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Xavier Leroy wrote: > > > I recommend the use of Invalid_argument to report "should never > happen" conditions at the boundary between library functions and user > code. On the other hand, the "Failure" exception is a bit of a legacy > from earlier designs (Caml Light and even the original LeLisp-based > Caml), and often is not the best way to report "normal error" > conditions: instead, you could consider defining your own exceptions > as Alain suggested, or even have your functions return "option" types > instead of raising exceptions. Where I work, we have come to dearly love the practice of returning polymorphic variants with explicit variants for various "normal" error cases. This is pretty lightweight, and is also very clear and explicit, both when looking at the function signature and at the call point. y ------=_Part_3433_16852063.1193223908464 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/24/07, Xavier Leroy <Xavier.Leroy@inria.fr> wrote:

I recommend the use of Invalid_argument to report "should never
happen" conditions at the boundary between library functions and user
code.  On the other hand, the "Failure" exception is a bit of a legacy
from earlier designs (Caml Light and even the original LeLisp-based
Caml), and often is not the best way to report "normal error"
conditions: instead, you could consider defining your own exceptions
as Alain suggested, or even have your functions return "option" types
instead of raising exceptions.

Where I work, we have come to dearly love the practice of returning polymorphic variants with explicit  variants for various "normal" error cases.  This is pretty lightweight, and is also very clear and explicit, both when looking at the function signature and at the call point.

y


------=_Part_3433_16852063.1193223908464--