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

["David Allsopp" <dra-news@metastack.com>]

> > While I think having clearer signatures is great,  I am still wary
> > that this solution might prove too much of a constraint in some cases.
> > I still think exceptions shouldn't be shunned so quickly. As their
> > name clearly stipulates they should be used to handle exceptional
> > cases, and sometimes the nature of what's an exceptional case is
> > better left to the programmer's judgment (e.g. find). I believe that,
> > when needed, both functions should be exposed in the interface (e.g.
> > find and find_exn, or find and find_opt).
>
> I stand behind the one liner that will make the error implicit if you  
> want. Explicit first, implicit if you want to take the risk.  
> Personnally I wouldn't make it implicit unless it is for an "assert  
> false", but this is a matter of philosophy.

Making the error explicit (i.e. using match) forces a decision on the client
of a library - and that breaks the golden rule of library design because
it's none of your business (as a library author) to force any decision on
the end-user of your library that is not necessary to maintain correct
operation of your library.

> > Exceptions are an amazing tool to handle exceptional cases because
> > they unwind stack the automatically.  This means that you don't have
> > to constantly thing about propagating the errors manually.
>
> I have nothing against exceptions per se. I also use them in my own  
> programs. But I don't want libraries to force me to use them. Recall  
> that the recommendation says nothing about client code. You can  
> perfectly define your own exceptions to propagate the error up.

But your proposal forces me to *use* 'a option when I want to *ignore*
exceptions. If I've got a map and, by proof, I know that I'll never do a
find on it that would raise Not_found then I sure don't want to wrap every
Map.find with either Option.get or a match clause.

I heartily approve of the notion of exceptions for exceptional cases as a
rule of thumb[*] - for example, many of the exceptions used in the Unix
module "should" definitely be 'a option (you should never perform I/O
without error checking, so 'a option - or, as I would use, ('a, 'b) result
is appropriate).

Furthermore, in the case of functions such as Map.find, the library author
*cannot* know whether failure to find an item in the map is exceptional or
not - and for that reason you cannot mandate 'a option as a return value -
the only real solution is to provide both functions and allow the client to
decide whether failure to find an item is exception or, failing that,
provide the path with the easiest wrapping - and I'm afraid that's
unarguably the exception route.

Incidentally, there's no need to benchmark to discover whether 'a option
wrapping is slower - it must be because it involves an extra allocation over
using exceptions. However, this difference is probably not that great (and
there are more possible compiler optimisations - though not necessarily
exploited by OCaml - that become possible if you don't use exceptions).


David


[*] Although IMHO "exceptions for exceptional circumstances" is a bit of a
beginners' mantra. Exceptions should be used in situations where you need to
unwind the stack - exceptional circumstances are one instance of this.
Another, equally valid, use of exceptions is in search algorithms - you may
be several stack levels down before discovering that a certain branch
decision was incorrect and using exception programming to unwind this is
much neater than passing values around.