2014-05-26 18:34 GMT+02:00 Daniel Bünzli <daniel.buenzli@erratique.ch>:

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:

Yes it could be annoying, but very high quality software become much harder to write. Refactoring is harder. Missing exception handler are harder to find.

* 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.

* 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.

That means intensive testing to be sur to avoid such failure for normal user input. For most long running programme (server, gui), that's could a problem.

For example, an undo/redo use lot of memory after some copy/paste on big data, then the save command have not enough memory to work, and the file are troncated. That's not acceptable, and can be see only with big data, after few high level command run.

Regards,
Nicolas

* 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.

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

--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs