Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Exceptionless error management
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-31 (20:05)
From: blue storm <bluestorm.dylc@g...>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
My two cents :

- It's easy to derive variant-defined functions from the
exception-using ones, with virtually no performance cost. Going the
other way is not as practical, and i assume it has a higher runtime
- We will need to document our functions in any case : the exception
name generally doesn't provide an accurate enough description of the
causes of the error (be it an exception, a polymorphic variant, ...)
- The added safety is good, but not (in my eyes) essential for every
use; we could use tools, eg. OcamlExc ( ) to
check the safety as well
- In most situation, exceptions allow for a more natural and more
concise code than options/variants/monads, precisely because they can
break flow of control (eg. in a "for" loop), and because our libs are
not quite adapted to that kind of programming now (where is mapM ?)

I would favor the conservative solution : still provide the exception
handling by default, and allowing an additional option/variants

On 1/31/08, David Teller <> wrote:
> Differentiating functions sounds like a good idea.
> We may either:
> * add a suffix after function names whenever they may raise exceptions
> (suffix "_exn" sounds good to me)
> * add a suffix after function names whenever they are variants that
> don't raise exceptions (say, suffix "_maybe")
> * write two different (sub)modules with the same set of functions, one
> module being named Exception, the other one being named Option.
> What else ? We could presumably functorize modules upon the definition
> of a error-delivery mechanism, but that might be overkill.
> Say
> module type ErrorMechanism = sig
>   type 't;                (**The type of a failure.*)
>   type 'a can_fail;
>                           (**The type of a value that can either succeed
>                              and produce a result of type 'a or fail and
>                              produce an error of type t. *)
>   value fail    : t -> 'a can_fail ;
>                           (**Fail. Depending on the mechanism, this may
>                              either return some variant on option or
>                              throw an exception.*)
>   value succeed : 'a -> 'a can_fail ;
>                           (**Succeed.*)
> end;;
> We could also introduce an exception monad which would be an
> intermediate choice between using exceptions and using option types and
> such. I have a just written a prototype for this, I'll try and release
> it soon.
> Cheers,
>  David
> On Thu, 2008-01-31 at 08:16 -0600, Michael Ekstrand wrote:
> > While `get' and `search' are probably OK (I presume that `get' raises
> > an exception, and `search' returns an option type), we must be
> > careful.  If multiple functions is the standard, I would prefer that a
> > naming/variant system be recommended (such as get and get_exn).  If we
> > come up with clever names for our various functions, I fear the Java
> > Queue API syndrome (where you can get a value with any of 4 different
> > functions, and add with another 4, that mostly differ in how they
> > handle error and thread blocking conditions and the names have little
> > correlation to the differences).
> >
> > - Michael
> --
> David Teller
>  Security of Distributed Systems
>  Angry researcher: French Universities need reforms, but the LRU act
> brings liquidations.
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: