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 q3BAWVHJ014675 for ; Wed, 11 Apr 2012 12:32:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUBAMpchU8machwl2dsb2JhbABFuT4qAQEBAQEGGAc7ggkBAQEEEgITGQEBNwEPCwsNLiISAQUBHAYTCBqHXgMLAwGbdwqKZIQuAYV9Iok4BpE/lXCOVj2ECw X-IronPort-AV: E=Sophos;i="4.75,404,1330902000"; d="scan'208";a="153543758" Received: from mx1.janestreet.com (HELO nyc-dmz-mxout1.janestreet.com) ([38.105.200.112]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2012 12:32:25 +0200 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHuqX-0006K1-S2 for caml-list@inria.fr; Wed, 11 Apr 2012 06:32:17 -0400 Received: from nyc-dmz-mxgoog1.delacy.com ([172.25.224.109] helo=mxgoog1.janestreet.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1SHuqX-0001ny-QT for caml-list@inria.fr; Wed, 11 Apr 2012 06:32:17 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]) by mxgoog1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1SHuqX-0000v8-JK for caml-list@inria.fr; Wed, 11 Apr 2012 06:32:17 -0400 Received: by wibhr14 with SMTP id hr14so677640wib.17 for ; Wed, 11 Apr 2012 03:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y55lmJy9XmQQWvQ6vd+tH3qXTePtrW14tlAnM55KL0M=; b=LrYEkj+FoCybVnHzfSL3zXjpwiyRSfoi+e6+vNWmkM9T06svJyVdjKbv4Ly9vyCqsL slTQDd2vbcQNP3Tq/c6cOrJIhBKQo4pX+qGycsoV+yUJ92IZYP8xq2TgHK8jvjgv1dmU goWoGA3wivoBXuxHolMq8k7er1AltRUbRf7GI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=Y55lmJy9XmQQWvQ6vd+tH3qXTePtrW14tlAnM55KL0M=; b=haobyClXicSff28E8vyNedDrIsC8bSl9p5wpGl5szqWIbJhPJy1J5w9naKNXkB/z/9 GNVC8SNHjLUehnacHk3Uwww1ESzgV5tTj21cPAIT8h1fxgmh2QLX+NHx3QkDaC433M/e bLUuKAuJCPm9Oz4EOpzcnIqmzW08FyMEIGcK9/W6WWWMiUg9mAqXUJ0iLISltvSdo4dW vTvzQuKUL9ZobRTD6F+ZvD8A38SbhuGq9Q94spqHTAfCot6bjpvgZSdU8M1LFUYoiwN7 SYQtEDztQIHqJaslR2/AXurRz3kUbbSgz53SBe++pbXJPjRe3199BVRjFmUINNWpRTQx b6lg== MIME-Version: 1.0 Received: by 10.180.80.9 with SMTP id n9mr15027947wix.4.1334140337021; Wed, 11 Apr 2012 03:32:17 -0700 (PDT) Received: by 10.216.235.148 with HTTP; Wed, 11 Apr 2012 03:32:16 -0700 (PDT) X-Originating-IP: [80.169.196.210] In-Reply-To: <87vcl6d0oe.fsf@frosties.localnet> References: <874nsy1rcd.fsf@frosties.localnet> <91EB03E665BB4D7BB3CC65466956C79B@erratique.ch> <87vcl6d0oe.fsf@frosties.localnet> Date: Wed, 11 Apr 2012 11:32:16 +0100 Message-ID: From: David House To: Goswin von Brederlow Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQljx7LEXHKG0gzs4n6bSG3kgcbBNxRQ3o+vWvF8ZVRjPpZ29pAr32k7BSR4rPaxh9nPQsZz Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3BAWVHJ014675 Subject: Re: [Caml-list] exn vs option On Wed, Apr 11, 2012 at 11:26 AM, Goswin von Brederlow wrote: >> 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]. *) > > That pattern works well if you have just one or few such functions and > can think of nice names to differentiate them. A common pattern that is convenient and clear is to append _exn to the functions that raise excetions on failure. This is used all over Core, and has the advantage that it is very obvious to client code that the call may raise an exception. A call to an _exn function without a try/with or a clearly true invariant is an indication that you might have a bug. (Not always; sometimes the appropriate behaviour to crash the program when some function fails.)