On 27 May 2014 09:49, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> * 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.

See https://blogs.janestreet.com/core-gems-many-happy-returns/ for how we solve this problem in core. The interface is very natural. It uses exceptions under the hood, although that is not exposed.

However, I think this is entirely separate from the rest of the discussion. Here we are merely using exceptions for their control flow properties -- there is no error condition.
 
Variants or option types are not always the best solution.

That's certainly true, although I would argue that exceptions are certainly overused. We use them quite a bit in core and in the rest of JS's codebase -- but only for truly "exceptional" circumstances.
 
> 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

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