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.2 required=5.0 tests=AWL 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 B8CB6BC6C for ; Thu, 31 Jan 2008 20:28:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKWvoUfAXQImh2dsb2JhbACQHwEBAQgKKZhS X-IronPort-AV: E=Sophos;i="4.25,286,1199660400"; d="scan'208";a="7486303" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2008 20:28:15 +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 m0VJSE8D015628 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 20:28:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEuwoUfBMVMQh2dsb2JhbACQHwEBAQgKKZhV X-IronPort-AV: E=Sophos;i="4.25,286,1199660400"; d="scan'208";a="8586448" Received: from minbis.univ-orleans.fr (HELO min.univ-orleans.fr) ([193.49.83.16]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 20:28:14 +0100 Received: from smtps.univ-orleans.fr (localhost [127.0.0.1]) by min.univ-orleans.fr (Postfix) with ESMTP id 8C4A212B415; Thu, 31 Jan 2008 20:28:13 +0100 (CET) Received: from [192.168.0.1] (lau18-1-82-246-197-195.fbx.proxad.net [82.246.197.195]) by smtps.univ-orleans.fr (Postfix) with ESMTP id D267D36E5B; Thu, 31 Jan 2008 20:28:16 +0100 (CET) Subject: Re: [Caml-list] [OSR] Exceptionless error management From: David Teller To: Michael Ekstrand Cc: caml-list@inria.fr In-Reply-To: <87myqmcc7v.fsf@jehiel.elehack.net> References: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@mail.gmail.com> <0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch> <47A1D68B.70700@fmf.uni-lj.si> <87myqmcc7v.fsf@jehiel.elehack.net> Content-Type: text/plain Date: Thu, 31 Jan 2008 20:28:12 +0100 Message-Id: <1201807692.6565.14.camel@Blefuscu> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 47A2214E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; univ-orleans:01 exn:01 variants:01 functorize:01 overkill:01 sig:01 cheers:01 exn:01 univ-orleans:01 lifo:01 liquidations:98 wrote:01 naming:01 exception:01 exception:01 Differentiating functions sounds like a good idea. We may either: * add a suffix after function names whenever they may raise exceptions (suffix "_exn" sounds good to me) * add a suffix after function names whenever they are variants that don't raise exceptions (say, suffix "_maybe") * write two different (sub)modules with the same set of functions, one module being named Exception, the other one being named Option. What else ? We could presumably functorize modules upon the definition of a error-delivery mechanism, but that might be overkill. Say module type ErrorMechanism = sig type 't; (**The type of a failure.*) type 'a can_fail; (**The type of a value that can either succeed and produce a result of type 'a or fail and produce an error of type t. *) value fail : t -> 'a can_fail ; (**Fail. Depending on the mechanism, this may either return some variant on option or throw an exception.*) value succeed : 'a -> 'a can_fail ; (**Succeed.*) end;; We could also introduce an exception monad which would be an intermediate choice between using exceptions and using option types and such. I have a just written a prototype for this, I'll try and release it soon. Cheers, David On Thu, 2008-01-31 at 08:16 -0600, Michael Ekstrand wrote: > While `get' and `search' are probably OK (I presume that `get' raises > an exception, and `search' returns an option type), we must be > careful. If multiple functions is the standard, I would prefer that a > naming/variant system be recommended (such as get and get_exn). If we > come up with clever names for our various functions, I fear the Java > Queue API syndrome (where you can get a value with any of 4 different > functions, and add with another 4, that mostly differ in how they > handle error and thread blocking conditions and the names have little > correlation to the differences). > > - Michael -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations.