Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Alain Frisch <alain@frisch.fr>
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
Date: Thu, 27 May 2010 11:34:38 +0200	[thread overview]
Message-ID: <4BFE3CAE.9090107@frisch.fr> (raw)
In-Reply-To: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>

On 05/26/2010 06:15 PM, Hans Ole Rafaelsen wrote:
> 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?

Indeed, this is mostly a matter of taste and style.

My personal "Rule #1" to decide to use exceptions or not is that one:

  Raising an exception is ok if you know where it will be caught
  or which global effect it will have on the application.


This includes the following cases:

- (Short jumps) Using exceptions locally as shortcuts in loops or more 
complex  algorithms. In that case, the runtime exception is encapsulated 
in a function or module, and should not cause any harm.

- (Long jumps) Using exceptions to report unexpected errors, to which 
the application has little chance to react in a clever way except 
displaying some error messages to the screen or to a log file. The catch 
point is a global exception handler, even though the code raising the 
exception (maybe in a general purpose library) might not know exactly 
how the application will react to the exception.  It is much better if 
the exception describes the problems in terms that can be understood by 
a human (Not_found, even with a stack trace, is not very helpful as an 
error message).

Library function that perform some kind of lookup should return an 
option type and let the caller raise a proper exception to report error 
in a way that makes sense for the application. Similarly for other kind 
of functions that can "fail": use a sum type (or polymorphic variants) 
instead to describe the possible "errors". A variant of the function 
that raises an exception is acceptable for cases where the caller really 
expect the function to succeed (it can fail only because of bugs in the 
application, not because of user or system errors). In that case, 
Assert_failure, or a custom exception, is probably better than 
Not_found. More generally, if exceptions are to be used, custom ones are 
usually better than generic ones (Failure, Invalid_argument).

Another interesting use of exceptions comes from the fact that exn is an 
extensible sum type. (Unfortunately, it is the only one in OCaml.) This 
enables some kinds of loosely typed scenarios, like notification 
messages to be dispatched across global objects in the application: the 
list of possible messages is not fixed in advance, and each object can 
simply use pattern matching to react on messages it is interested in. 
But this is another story...



Alain



  reply	other threads:[~2010-05-27  9:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-26 16:15 Hans Ole Rafaelsen
2010-05-27  9:34 ` Alain Frisch [this message]
2010-05-27 17:01 ` [Caml-list] " 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
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
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
2010-06-01 19:08 Peter Ronnquist

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=4BFE3CAE.9090107@frisch.fr \
    --to=alain@frisch.fr \
    --cc=caml-list@inria.fr \
    --cc=hrafaelsen@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