caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
To: caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Fri, 1 Feb 2008 12:31:52 +0100	[thread overview]
Message-ID: <2F3349DE-E200-4147-A5ED-78366A636D9E@erratique.ch> (raw)
In-Reply-To: <9d3ec8300802010250n5921415r36eb7f9773ef3681@mail.gmail.com>


Le 1 févr. 08 à 11:50, Till Varoquaux a écrit :

> 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).

I stand behind the one liner that will make the error implicit if you  
want. Explicit first, implicit if you want to take the risk.  
Personnally I wouldn't make it implicit unless it is for an "assert  
false", but this is a matter of philosophy.

> 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.

I have nothing against exceptions per se. I also use them in my own  
programs. But I don't want libraries to force me to use them. Recall  
that the recommendation says nothing about client code. You can  
perfectly define your own exceptions to propagate the error up.

> 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.

On the safety bit I think this is less true if you actually take care  
to close your variants. However I tend to agree on the clearer  
separation of cases. I added a request for comments on this at the end  
of the OSR page to standardize on [ `Value of ... | `Error of ... ]  
instead of [ `Value of ... | .... ].

Best,

Daniel


  reply	other threads:[~2008-02-01 11:31 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
2008-02-01 11:31               ` Bünzli Daniel [this message]
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=2F3349DE-E200-4147-A5ED-78366A636D9E@erratique.ch \
    --to=daniel.buenzli@erratique.ch \
    --cc=caml-list@inria.fr \
    /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).