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]. *)
Best,
Daniel
P.S. [Invalid_argument] is used for programming errors. This pattern expresses
an opinion about using exceptions.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
