caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si>
To: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
Cc: Till Varoquaux <till.varoquaux@gmail.com>,
	caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Thu, 31 Jan 2008 15:09:15 +0100	[thread overview]
Message-ID: <47A1D68B.70700@fmf.uni-lj.si> (raw)
In-Reply-To: <0640C30E-07B5-4885-AC38-671755BB79AA@erratique.ch>

Bünzli Daniel wrote:
> let find map k = 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?

Throwing out functionality on the grounds that it "clutters APIs" 
doesn't sound like a good idea to me. Throwing out bells and whistles is 
another matter.

Andrej


  reply	other threads:[~2008-01-31 14:09 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31  8:55 Bünzli Daniel
2008-01-31  9:57 ` [Caml-list] " Till Varoquaux
2008-01-31 11:01   ` Bünzli Daniel
2008-01-31 14:09     ` Andrej Bauer [this message]
2008-01-31 14:16       ` Michael Ekstrand
2008-01-31 19:28         ` David Teller
2008-01-31 19:59           ` Michael Ekstrand
2008-01-31 20:05           ` blue storm
2008-01-31 20:03       ` Bünzli Daniel
2008-01-31 20:25         ` David Teller
2008-01-31 20:40           ` David Teller
2008-01-31 21:16           ` Bünzli Daniel
2008-01-31 21:31             ` David Teller
2008-01-31 21:35           ` Jon Harrop
2008-01-31 22:01           ` Christophe Raffalli
2008-02-01  7:27         ` Michaël Grünewald
2008-02-01  7:47           ` Bünzli Daniel
2008-02-01 10:50             ` Till Varoquaux
2008-02-01 11:31               ` Bünzli Daniel
2008-02-01 15:59                 ` Vincent Hanquez
2008-02-01 18:37                   ` Bünzli Daniel
2008-02-01 19:43                     ` Vincent Hanquez
2008-02-01 16:04                 ` David Allsopp
2008-02-01  8:31 ` David Teller
2008-02-01 12:19   ` Yaron Minsky
2008-02-05 10:00 ` David Teller
2008-02-05 10:12   ` Vincent Hanquez
2008-02-05 10:26     ` Bünzli Daniel
2008-02-05 11:06       ` Vincent Hanquez
2008-02-05 13:46         ` Jon Harrop
2008-02-05 11:36       ` Frédéric van der Plancke
2008-02-06  8:45       ` Michaël Grünewald
2008-02-08 13:09         ` Bünzli Daniel
2008-02-05 14:12     ` David Teller
2008-02-11  8:12 ` David Teller
2008-02-11  9:09   ` Bünzli Daniel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47A1D68B.70700@fmf.uni-lj.si \
    --to=andrej.bauer@fmf.uni-lj.si \
    --cc=Andrej.Bauer@andrej.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    --cc=till.varoquaux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).