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