Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Florent Ouchet <florent.ouchet@imag.fr>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
Date: Thu, 27 May 2010 10:08:33 +0200	[thread overview]
Message-ID: <4BFE2881.1070705@imag.fr> (raw)
In-Reply-To: <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>

Hello,

Same here, specially to avoid the Not_found exception.
The optional return values gives the oportunity to have a clear view of 
what is being done if the result is not available.

- Florent

Jacques Le Normand a écrit :
> Jane Street's Core seems to prefer options to exceptions
>
> On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen 
> <hrafaelsen@gmail.com <mailto:hrafaelsen@gmail.com>> wrote:
>
>
>
>     On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira
>     <darioteixeira@yahoo.com <mailto:darioteixeira@yahoo.com>> wrote:
>
>         Hi,
>
>         > What experience does people have to using alternatives to
>         exceptions,
>         > such as option types or exception monads? Does use of third part
>         > libraries that still throws exceptions make such approaches
>         hard to use?
>         > Performance wise it seems to be comparable to catching
>         exceptions or
>         > matching for options, so I guess the difference be might a
>         question of
>         > programming style?
>
>         Partly yes, though I would say that in Ocaml it is tempting to use
>         exceptions beyond what is reasonable, because they are so
>         cheap and
>         convenient.  As you noted, this can lead to trouble at
>         runtime, which
>         is why some libraries discourage the "exceptional style",
>         preferring
>         option types and forcing users to invoke functions suffixed by
>         "_exc"
>         if they really want to use the exception-based version.
>
>         Personally, I think the litmus test hinges on whether the
>         supposedly
>         exceptional situation is truly worthy of the name.  If it's a
>         common
>         occurrence, perhaps one should reconsider the use of an
>         "exception".
>         Without meaning to start an holy war, let me just add that even on
>         the Stdlib there are functions (such as Map.S.find) that raise an
>         exception but which should perhaps return an option type.
>
>         Btw, you didn't mention it explicitly in your message, but I
>         trust you
>         are familiar with "Catch me if you can"? [1]
>
>     I have just read about it, not tested it yet. Do you have any
>     experience using this library, especially together with other
>     libraries that also provides syntax extension?
>      
>
>
>         Best regards,
>         Dario Teixeira
>
>         [1]
>         http://dutherenverseauborddelatable.wordpress.com/downloads/exception-monads-for-ocaml/
>
>
>
>
>     Thanks,
>
>     Hans Ole
>
>     _______________________________________________
>     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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>   


-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory



  reply	other threads:[~2010-05-27  8:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 17:30 Dario Teixeira
2010-05-26 21:10 ` Hans Ole Rafaelsen
2010-05-27  3:37   ` Jacques Le Normand
2010-05-27  8:08     ` Florent Ouchet [this message]
2010-05-27  8:50       ` Eray Ozkural
2010-05-27 11:10         ` Florent Ouchet
2010-05-27  8:54       ` David Allsopp
2010-05-27  9:11         ` Mark Shinwell
2010-05-27  9:29           ` David Allsopp
2010-05-27  9:12         ` Daniel Bünzli
2010-05-27  9:19           ` David Allsopp
2010-05-27  9:15       ` David Rajchenbach-Teller
2010-05-27 13:56     ` Hezekiah M. Carty
  -- strict thread matches above, loose matches on Subject: below --
2010-06-01 19:08 Peter Ronnquist
2010-05-26 16:15 Hans Ole Rafaelsen
2010-05-27  9:34 ` [Caml-list] " Alain Frisch
2010-05-27 17:01 ` Richard Jones
2010-05-27 21:13   ` Dario Teixeira
2010-05-31 14:36   ` Goswin von Brederlow
2010-05-31 15:00     ` Florent Ouchet
2010-05-31 17:24     ` David Allsopp
2010-05-31 20:51       ` Török Edwin
2010-06-08  9:16       ` Goswin von Brederlow
2010-05-31 19:30     ` Nicolas Pouillard
2010-05-31 20:57       ` Lukasz Stafiniak
2010-05-31 21:42         ` blue storm
2010-05-31 19:36     ` Christophe Raffalli

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=4BFE2881.1070705@imag.fr \
    --to=florent.ouchet@imag.fr \
    --cc=caml-list@yquem.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