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-02-05 (14:12)
From: David Teller <David.Teller@u...>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
On Tue, 2008-02-05 at 11:12 +0100, Vincent Hanquez wrote:
> On Tue, Feb 05, 2008 at 11:00:44AM +0100, David Teller wrote:
> >  The debate on this subject seems to have calmed down. A tentative set
> > of recommendations have been put together on the wiki [1] by some of the
> > participants. It looks coherent and well-written. If nothing springs
> > back to the front of the scene within a few days, I'll post this again
> > to the mailing-list as a call for votes.
> looking at the page, I find a proposal (beginning), and a lots of people
> disaggreeing at the end.
> I can see lots of people are concerned by using polymorphic variant (and
> I certainly agree with those), and people asking for a monadic approch
> (haskell's either like). I can see anything change in the proposal
> regarding people's concerned, so what are you going to call for a vote ?

Ok, my bad, I guess I misunderstood silence for consensus.

In this case, let me try and sum up the discussion. I'll use the term
"exception" for OCaml's built-in exception system.

1) This recommendation applies to functional libraries, by opposition to
essentially imperative libraries such as Unix.
[ I believe everybody agrees with that ]

2) This recommendation only applies to the interface of libraries,
rather than their non-observable implementation or their use by clients.
[ I believe everybody agrees with that ]

3) Exceptions passing library barriers should be reserved for programmer
errors (i.e. invalid arguments and impossible-to-reach states) rather
than previsible errors (e.g. sometimes, a key does not map to a value).
We already have standard names for such exceptions.
[ I have the impression nobody disagrees with that, either ]

4) At hand, to provide non-exception error management, we have the
following tools:
* 'a option 
* something such as ('a, 'b) either  -- exact name and constructors
remain to be decided, but the general idea is there -- which may serve,
if necessary, as the base for error monads
* polymorphic variants
* an implementation of error monad based on exceptions, which may be
trivially degraded to   ('a, 'b) either   whenever necessary.

(I'm discounting my own suggestion for functor-based error reporting as
I haven't had time to work on that, plus it would actually solve a
different problem)

[ Unless I'm mistaken, these are the only tools suggested so far ]

5) We may need to differentiate functions which raise exceptions.
Someone on this thread suggested adding suffix "_exn" to the name of
such functions. Another possibility would be to define a type such as
  type 'a raising = 'a
to document the fact that a function may raise an exception.

[ No discussion on this yet ]

6) Assuming that no other tools come into the discussion, we need to
determine which tools are best for which situation.

There seems to be an agreement that polymorphic variant are too fragile
for general use. This leaves us essentially 
* ('a,'b) either  (of which 'a option is just a special case)
* the exception-based error monad, with the ability to produce results
of type 'a or errors of type 'b . 

These cases are fundamentally equivalent, each may be used to build the
other and result in essentially the same type signature.

[ No discussion on this yet ]

7) Assuming that we use one of these two possibilities, we need to
decide what to put in the 'b. 

Here, we may decide to:
* either define module-specific types ; 
* or use polymorphic variants.

Again, the general consensus seems to be that polymorphic variants are
too risky. On the other hand, we may also decide not to specify at all
what to put in 'b and to let each developer decide for their own

[ No discussion on this yet ]

As a test, I've adapted the interface of the List module.
* I've included the interface for both possibilities
* I've postfixing exception-raising functions with "_exn"
* I've defined module-specific sum types, some of which could presumably
be moved to Pervasives.

You may find the result here: 


David Teller
 Security of Distributed Systems
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations.