Re: [Caml-list] [OSR] Exceptionless error management

["Bünzli Daniel" <daniel.buenzli@erratique.ch>]

Le 31 janv. 08 à 10:57, Till Varoquaux a écrit :

> My cocan account is not created yet soo I will answer here:

I think it is better to discuss on the list.

> _ In the thread you are pointing to Xavier did not say using
> exceptions was a mistake, he said the Failure exception (such as
> int_of_string) was legacy code and not great.

Right, corrected.

> _ Allowing Invalid_argument seems a little to hardcore. When doing
> system programming for instance there is an incredible range of
> exceptional events that can happen, you are definitly not going to
> handle all of them (or are you?) so you will need to let them trickle
> up. This will eventually require using something akin to an error
> monad and some awfull mangling with polymorpic variants.

This OSR is mainly targeted at reusable modules and it says nothing  
about clients of the module. Clients are allowed to define their own  
exceptions to propagate the error up. The contract of a conforming  
module is that it won't interfere with the client's control flow as  
long as it behaves correctly.

> _Exceptions are terse. Suppose Map.find returned an option type (and
> this seems a sensible choice). If you were in a place where not being
> in the map really was an exceptional event you'd need to unbox and do
> some error handling for every lookup (and since you do not want to
> raise an exception I must wonder what you would do).

They are terse because they are implicit and I don't like this. For me  
either not being in the map can happen and then you have to deal with  
it at each call because of program correctness either you know, e.g.  
by construction, that not being in the map cannot happen. In the  
latter case I would define the following local function :

let find map k = match Map.find map k with Some v -> v | None ->  
assert false

> _For functions like find... declare two functions: one that boxes it's
> return value (i.e val input_line : in_channel -> string option) and
> another that raises an exception (i.e val input_line_exn : in_channel
> -> string).

Requiring this clutters apis and is more work for the module  
developer. If you want a function that raises you can define your own  
local function as suggested above.

Best,

Daniel