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
overhead
- 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 (
http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm ) 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
version.

On 1/31/08, David Teller <David.Teller@univ-orleans.fr> 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
>   http://www.univ-orleans.fr/lifo/Members/David.Teller
>  Angry researcher: French Universities need reforms, but the LRU act
> brings liquidations.
>
> _______________________________________________
> 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
>