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.0 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 3A051BC6C for ; Thu, 31 Jan 2008 12:01:35 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADs5oUfAXQImh2dsb2JhbACQKwEBAQgKKZd5g0U X-IronPort-AV: E=Sophos;i="4.25,284,1199660400"; d="scan'208";a="7465897" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2008 12:01:35 +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 m0VB1YT1027336 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 12:01:34 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAP44oUdC+VLqmGdsb2JhbACQKwEBAQEBBgIGCQoYl3eDRQ X-IronPort-AV: E=Sophos;i="4.25,284,1199660400"; d="scan'208";a="8568020" Received: from wx-out-0506.google.com ([66.249.82.234]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 12:01:33 +0100 Received: by wx-out-0506.google.com with SMTP id h28so895077wxd.0 for ; Thu, 31 Jan 2008 03:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=3PhaThbSusbgQSyHRC5+aYKZSVKi+jJ3/MrAKO2ImQc=; b=Zml+MemZwpm+zIjqF3yQKROEYhGzSBr0Ul7NuQjnYLwuclmd1tGWonfvjKcRsQVHFYbixfv3jBAAXq5d8cycD+p9BcB+hGMCqn574vy18I/JUd9IywjangfinxuHUO7iBKTMWufwQgHnxNyyV5mnYrIk1SLyh+EY30fV3XDfv3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=O9tAy715rKohcfRnLWnpdk7xsKMyguPMNQmQ37/LuimGElSdRsTCv94U+SWPbgiDA1+zFhWIOA6m5L45EU8yZ9jpSio2wqRgox2I2e/Li+w9JocX4FiW+RY6Nf8zKl4Id1Pdnrob6zITs+mHiPNjOSGx3OfT+05Nat+CYi4RoNU= Received: by 10.150.49.15 with SMTP id w15mr623860ybw.101.1201777292296; Thu, 31 Jan 2008 03:01:32 -0800 (PST) Received: from ?192.168.1.58? ( [85.2.98.179]) by mx.google.com with ESMTPS id d26sm964802nfh.25.2008.01.31.03.01.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Jan 2008 03:01:31 -0800 (PST) Cc: "caml-list List" Message-Id: <0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch> From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: "Till Varoquaux" In-Reply-To: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@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: Thu, 31 Jan 2008 12:01:33 +0100 References: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@mail.gmail.com> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at discorde with ID 47A1AA8E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 mangling:01 variants:01 val:01 val:01 exn:01 hardcore:98 client's:98 exception:01 exception:01 assert:01 corrected:01 caml-list:01 functions:01 Le 31 janv. 08 =E0 10:57, Till Varoquaux a =E9crit : > My cocan account is not created yet soo I will answer here: I think it is better to discuss on the list. > _ In the thread you are pointing to Xavier did not say using > exceptions was a mistake, he said the Failure exception (such as > int_of_string) was legacy code and not great. Right, corrected. > _ Allowing Invalid_argument seems a little to hardcore. When doing > system programming for instance there is an incredible range of > exceptional events that can happen, you are definitly not going to > handle all of them (or are you?) so you will need to let them trickle > up. This will eventually require using something akin to an error > monad and some awfull mangling with polymorpic variants. This OSR is mainly targeted at reusable modules and it says nothing =20 about clients of the module. Clients are allowed to define their own =20 exceptions to propagate the error up. The contract of a conforming =20 module is that it won't interfere with the client's control flow as =20 long as it behaves correctly. > _Exceptions are terse. Suppose Map.find returned an option type (and > this seems a sensible choice). If you were in a place where not being > in the map really was an exceptional event you'd need to unbox and do > some error handling for every lookup (and since you do not want to > raise an exception I must wonder what you would do). They are terse because they are implicit and I don't like this. For me =20= either not being in the map can happen and then you have to deal with =20= it at each call because of program correctness either you know, e.g. =20 by construction, that not being in the map cannot happen. In the =20 latter case I would define the following local function : let find map k =3D match Map.find map k with Some v -> v | None -> =20 assert false > _For functions like find... declare two functions: one that boxes it's > return value (i.e val input_line : in_channel -> string option) and > another that raises an exception (i.e val input_line_exn : in_channel > -> string). Requiring this clutters apis and is more work for the module =20 developer. If you want a function that raises you can define your own =20= local function as suggested above. Best, Daniel=