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
next prev parent 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