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

[David House <dhouse@janestreet.com>]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 3134 bytes --]