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: -- (:)
From: David Teller <David.Teller@u...>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
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. 

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 ;

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.


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.