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.0 required=5.0 tests=none 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 CDACEBC6C for ; Thu, 31 Jan 2008 15:16:29 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPdmoUfAXQImh2dsb2JhbACQKwEBAQgKKYEUmGA X-IronPort-AV: E=Sophos;i="4.25,285,1199660400"; d="scan'208";a="7473882" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2008 15:16:29 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0VEGIeH002941 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 15:16:29 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPdmoUfY87Fk/2dsb2JhbACRfZhg X-IronPort-AV: E=Sophos;i="4.25,285,1199660400"; d="scan'208";a="6781583" Received: from elehack.net ([216.243.177.100]) by mail2-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2008 15:16:24 +0100 Received: by ahijah.elehack.net (Postfix, from userid 1001) id DE8E52E04B; Thu, 31 Jan 2008 08:17:15 -0600 (CST) To: caml-list@inria.fr Subject: Re: [Caml-list] [OSR] Exceptionless error management References: <9d3ec8300801310157r77b86fc0k80f40b1df36091c2@mail.gmail.com> <0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch> <47A1D68B.70700@fmf.uni-lj.si> From: Michael Ekstrand Date: Thu, 31 Jan 2008 08:16:04 -0600 In-Reply-To: <47A1D68B.70700@fmf.uni-lj.si> (Andrej Bauer's message of "Thu\, 31 Jan 2008 15\:09\:15 +0100") Message-ID: <87myqmcc7v.fsf@jehiel.elehack.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Miltered: at discorde with ID 47A1D832.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 andrej:01 andrej:01 runtime:01 exn:01 gpg:01 wrote:01 naming:01 exception:01 exception:01 assert:01 caml-list:01 functions:01 functions:01 exceptions:01 X-Attachments: cset="utf-8" type="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrej Bauer writes: > B=C3=BCnzli Daniel wrote: >> let find map k =3D match Map.find map k with Some v -> v | None -> >> assert false > > I have become to prefer option types as return values (as opposed to > exceptions), but I admit it can be annoying to always consider both > possibilities, especially if you know that "None" won't happen. If the > library only provides "find" that returns an option type, the above > solution gets around constant checking. But how much runtime overhead > does it cause? Has anyone measured that? > > What is wrong with having two functions? With a bit of imagination, we > can give them reasonable names, e.g., get and search. Everybody can > guess which one returns the option type and which one throws an > exception, right? 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). =2D Michael =2D-=20 mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see . --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHodgtJMBfXHjb5YURAi/IAJ9uQcerLc2x4dOOqfRZJDx0aB715QCeJfA7 fq46Gh7p0I61R8RIcdTWZzA= =FHnf -----END PGP SIGNATURE----- --=-=-=--