Re: [Caml-list] Uncaught exceptions in function type.

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

On Mon, May 26, 2014 at 06:34:33PM +0200, Daniel Bünzli wrote:
> Le lundi, 26 mai 2014 à 18:02, Philippe Veber a écrit :
> > Thanks! BTW core still uses exceptions. Is there an explicit rule as to how to decide between Result type or exceptions. For instance, why not write the Array.create function like this:
> >  
> > val create : int -> 'a -> 'a array Or_error.t
> >  
> > where create fails for a negative integer?
> Because that would be utterly annoying. You need to make the
> following distinctions:
> 
> * Programming errors, for contracts with the programmer that cannot
> be enforced through types. For that raises Invalid_argument if the
> contract is violated. Invalid_argument is not supposed to be handled,
> it denotes an API misuse, like calling Array.create with a negative
> integer.

Sometimes arguments are computed and suddenly exceed aceptable
parameters. E.g. the user specifies a data file that needs to be read
into a string. If the file is too large you get Invalid_argument.
Programms can catch and handle such cases, at least to the point of
giving a good error message.

Idealy a program should catch all exceptions and explain in a human
readable way why they happened.
 
> * Exceptional errors, for errors that the programmer is unlikely to
> handle at all (e.g. out of memory). For that raise a custom exception.
> This should occur very rarely, you are unlikely to ever define one
> such exception.

Out of memory is probably the only exception you can't do anything
about in ocaml. Catching and handling it would nearly always need more
ram causing just another Ouf_of_memory exception. In ocaml you are
pretty much screwed.
 
> * Non-exceptional errors, errors that the programmer will have to
> handle (e.g. failing to connect a socket), for that do not use a
> custom exception but use variants or options types.  

That is a matter of taste and with recursions in the mix exceptions
can be a great way to abort the recursion while keeping the code flow
simple. They also allow you to use things like List.fold_left and
abort early.

Variants or option types are not always the best solution.
 
> In general if you write libraries it???s better to err on the side
> of exceptionless design: never use exceptions beyond Invalid_argument
> (and especially never use Not_found or Failure). Leave exception
> definition/usage at the discretion of the user (if he wishes to shoot
> himself in the foot).
> 
> Best,
> 
> Daniel

MfG
	Goswin