caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Till Varoquaux" <till.varoquaux@gmail.com>
To: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
Cc: "caml-list List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Fri, 1 Feb 2008 10:50:24 +0000	[thread overview]
Message-ID: <9d3ec8300802010250n5921415r36eb7f9773ef3681@mail.gmail.com> (raw)
In-Reply-To: <89B95036-D3D1-41FD-B99A-ED46D54BF89E@erratique.ch>

I am still very ambivalent:

While I think having clearer signatures is great,  I am still wary
that this solution might prove too much of a constraint in some cases.
I still think exceptions shouldn't be shunned so quickly. As their
name clearly stipulates they should be used to handle exceptional
cases, and sometimes the nature of what's an exceptional case is
better left to the programmer's judgment (e.g. find). I believe that,
when needed, both functions should be exposed in the interface (e.g.
find and find_exn, or find and find_opt).

Exceptions are an amazing tool to handle exceptional cases because
they unwind stack the automatically.  This means that you don't have
to constantly thing about propagating the errors manually. A monad
can, of course, help with this, but there is a cost in code clarity to
consider. They can also help you identify the source of issues by
giving a back trace that is ultimately printed at the root of your
program (very hard to achieve without exceptions).

Choosing whether an error case should be treated as an exception is a
matter which, IMHO, does not have a general answer and depends on:
- How often the errors can occur and how they can be treated
- How safe you require your API to be. If you run with tight security
restrictions you will probably be more likely to take the
exception-less route. Note that taking a radical stance (like the one
advocated in your OSR) might make your programs a lot more verbose
and/or harder to grasp. Simplicity also leads to better security.
- Personal tastes.

I am also not very enthused by the use of the polymorphic variant
versus a Haskell like [Left | Right] variant. I think the former can
lead to hard to track errors (excerpt from the manual: "Beware also
that some idioms make trivial errors very hard to find.") bringing an
illusion of safety rather than safety itself. The latter also
separates in clearer way the error cases from the success cases.

Just my 0.02 (euro) cents.

Till

On Feb 1, 2008 7:47 AM, Bünzli Daniel <daniel.buenzli@erratique.ch> wrote:
>
> Le 1 févr. 08 à 08:27, Michaël Grünewald a écrit :
>
> > Bünzli Daniel <daniel.buenzli@erratique.ch> writes:
> >
> >>> time jot 1000000 | ./in.native
> >>
> >> real 0m4.814s
> >> user 0m4.371s
> >> sys  0m0.218s
> >
> > You are timing `jot' aren't you?
>
> Not really, only half of the time. See at the end of this email.
>
> > The recommendation you proposed would be even more useful if it
> > emphasizes when ``Exceptionless error management'' is adequate.
>
> Right. I'll try to do something along this line. I'll will highlight
> in the suggestions part (which is not part of the recommendation) that
> in Unix-like cases the recommendation should maybe not be followed.
>
> Best,
>
> Daniel
>
>
>  > jot 1000000 > lines.txt
>
>  > time ./in.native < lines.txt
>
> real    0m6.093s
> user    0m2.132s
> sys     0m0.219s
>
>  > time ./inb.native < lines.txt
>
> real    0m6.827s
> user    0m2.117s
> sys     0m0.218s
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
http://till-varoquaux.blogspot.com/

  reply	other threads:[~2008-02-01 10:50 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
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 [this message]
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=9d3ec8300802010250n5921415r36eb7f9773ef3681@mail.gmail.com \
    --to=till.varoquaux@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /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).