Re: [Caml-list] exn vs option

[Goswin von Brederlow <goswin-v-b@web.de>]

Daniel Bünzli <daniel.buenzli@erratique.ch> writes:

> Le jeudi, 5 avril 2012 à 11:05, Goswin von Brederlow a écrit :
>> If you are writing a module then consider providing both flavours for
>> functions, one with exceptions and one with options. Even if you only do
>> something like this:
>
>
> I don't think it's a rule that should be applied consistently, I don't like libraries that provide tons of convenience functions, too many names. If you stick with the option type (or variant cases) the user can quickly wrap the function if it needs an exception (or vice-versa but I prefer it that way since it's then documented by the function signature and is in my opinion better behaved in general).
>
> However in the particular case of finding something in a data structure where the user could be confronted with a situation where he can prove that the datum will be found I think it's justified to provide both flavours. For these cases, in my own code I settled on the following pattern :  
>
>     val find : 'a t -> key -> 'a option
>     (** [find d k] is the value bound to [k] in [d], if any. *)
>
>     val get : 'a t -> key -> 'a  
>     (** [get d k] is like {!find} but raises [Invalid_argument] if [k] is not bound in [d]. *)

That pattern works well if you have just one or few such functions and
can think of nice names to differentiate them.

Otherwise submodules are usefull:

module Foo = Foo.Options
or
module Foo = Foo.Exceptions

Foo.do_things ()

or

open Foo.Options
do_things ()

The option and exception raising functions would be named the same and
the user selects one or the other by selecting a submodule.

As said, it is usualy a matter of taste and the users tastes might
differ from the module authors taste. By providing an option and
execption flavour of a function (by different names or submodules hardly
matters) the user can use what he likes as opposed to what the modules
author imposes on him.

MfG
        Goswin