From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q359oNl8013727
	for <caml-list@sympa-roc.inria.fr>; Thu, 5 Apr 2012 11:50:25 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgCAPFpfU9KN1ZKm2dsb2JhbABFhW+zGwEBAQEBCAkLCRQnggoBBSMEYgsaAhgOAgI9ChAhiAYEqEqSaYEvjAeCDDVjBJtIjUA
X-IronPort-AV: E=Sophos;i="4.75,374,1330902000"; 
   d="scan'208";a="152818576"
Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Apr 2012 11:50:25 +0200
Received: from heyho.local (83-232.197-178.cust.bluewin.ch [178.197.232.83])
	by smtp.webfaction.com (Postfix) with ESMTP id 5A8F226ECF5A
	for <caml-list@inria.fr>; Thu,  5 Apr 2012 04:50:22 -0500 (CDT)
Date: Thu, 5 Apr 2012 11:50:17 +0200
From: =?utf-8?Q?Daniel_B=C3=BCnzli?= <daniel.buenzli@erratique.ch>
To: caml-list@inria.fr
Message-ID: <91EB03E665BB4D7BB3CC65466956C79B@erratique.ch>
In-Reply-To: <874nsy1rcd.fsf@frosties.localnet>
References: <CAGyUfm0SkjTVZ4hcQRNGThWWzGoXbbVnBXHBDcr1jP=6cFCMkQ@mail.gmail.com>
 <874nsy1rcd.fsf@frosties.localnet>
X-Mailer: sparrow 1.5 (build 1043.1)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q359oNl8013727
Subject: Re: [Caml-list] exn vs option

Le jeudi, 5 avril 2012 à 11:05, Goswin von Brederlow a écrit :
> If you are writing a module then consider providing both flavours for
> functions, one with exceptions and one with options. Even if you only do
> something like this:


I don't think it's a rule that should be applied consistently, I don't like libraries that provide tons of convenience functions, too many names. If you stick with the option type (or variant cases) the user can quickly wrap the function if it needs an exception (or vice-versa but I prefer it that way since it's then documented by the function signature and is in my opinion better behaved in general).

However in the particular case of finding something in a data structure where the user could be confronted with a situation where he can prove that the datum will be found I think it's justified to provide both flavours. For these cases, in my own code I settled on the following pattern :  

    val find : 'a t -> key -> 'a option
    (** [find d k] is the value bound to [k] in [d], if any. *)

    val get : 'a t -> key -> 'a  
    (** [get d k] is like {!find} but raises [Invalid_argument] if [k] is not bound in [d]. *)

Best,

Daniel

P.S. [Invalid_argument] is used for programming errors. This pattern expresses an opinion about using exceptions.