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.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 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 A4769BC69 for ; Thu, 25 Oct 2007 09:02:45 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI7cH0fUGyojimdsb2JhbACBWo0AAgEIAggREQc X-IronPort-AV: E=Sophos;i="4.21,328,1188770400"; d="scan'208";a="3621446" Received: from smtp5-g19.free.fr ([212.27.42.35]) by mail1-smtp-roc.national.inria.fr with ESMTP; 25 Oct 2007 09:02:45 +0200 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id D13B13F615A; Thu, 25 Oct 2007 09:02:44 +0200 (CEST) Received: from Llea.celt.neu (ron34-3-82-236-236-194.fbx.proxad.net [82.236.236.194]) by smtp5-g19.free.fr (Postfix) with ESMTP id A930B3F6194; Thu, 25 Oct 2007 09:02:44 +0200 (CEST) Received: from Llea.celt.neu (localhost [127.0.0.1]) by Llea.celt.neu (8.14.1/8.13.8) with ESMTP id l9P773H9001270; Thu, 25 Oct 2007 09:07:03 +0200 (CEST) (envelope-from michael.le_barbier@laposte.net) Received: (from michael@localhost) by Llea.celt.neu (8.14.1/8.13.8/Submit) id l9P77316001269; Thu, 25 Oct 2007 09:07:03 +0200 (CEST) (envelope-from michael.le_barbier@laposte.net) X-Authentication-Warning: Llea.celt.neu: michael set sender to michael.le_barbier@laposte.net using -f To: Xavier Leroy Cc: =?iso-8859-15?Q?Micha=EBl?= Le Barbier , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Preferred use of Invalid_argument and Failure References: <867ildqacq.fsf@Llea.celt.neu> <471EFD20.5010303@inria.fr> From: =?iso-8859-15?Q?Micha=EBl?= Le Barbier Date: Thu, 25 Oct 2007 09:07:03 +0200 In-Reply-To: <471EFD20.5010303@inria.fr> (Xavier Leroy's message of "Wed\, 24 Oct 2007 10\:06\:56 +0200") Message-ID: <86abq7ad0o.fsf@Llea.celt.neu> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; assertion:01 recovers:01 syntax:01 advices:01 frisch:01 computations:01 advices:01 cheers:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 exceptions:01 Xavier Leroy writes: > The convention that the standard library tries to follow is this. > > Invalid_argument is very much like a failed assertion: it indicates > that something is wrong in the program itself, i.e. negative character > positions in string functions. Most programs will not catch > Invalid_argument, treating as a fatal error. Others will catch it, > but only to enter a piece of generic "recover from unexpected error" > code. > > Failure, on the other hand, signals errors that can happen in normal > runs of the code. For instance, you're converting a user-provided > string to a number, and the string does not represent a number. It is > expected that the client code catches Failure and recovers gracefully, > e.g. by asking for the number again, or producing a precise "syntax > error" message. > > 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. Thank you very much for your description of the error reporting scheme used in the standard library, you made the things very clear. Following your joined advices with Alain Frisch, I will rethink error reporting scheme in that library to provide more accurate error diagnostics. Accurate errors are clearly more useful than vague ones. I suppose the ``right thing to do'' depends greatly of the application type. Specifically, I am working on a program that do scientific computations, and I am very interesting in getting a precise description of parameters that crashed my program: throwing exception seems a convenient way to provide this feedback. Thanks again to all contributors for their valuable advices. --=20 Cheers, Micha=EBl