On Wed, Apr 11, 2012 at 11:26 AM, Goswin von Brederlow
<goswin-...@web.de> wrote:
>> 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.
A common pattern that is convenient and clear is to append _exn to the
functions that raise excetions on failure.
This is used all over Core, and has the advantage that it is very
obvious to client code that the call may raise an exception. A call to
an _exn function without a try/with or a clearly true invariant is an
indication that you might have a bug. (Not always; sometimes the
appropriate behaviour to crash the program when some function fails.)
--
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
