Re: [Caml-list] What if exn was not an open type?

[Malcolm Matalka <mmatalka@gmail.com>]

Nathan Moreau <nathan.moreau@m4x.org> writes:

> Exceptions being an open type allows you to classify failures.
>
> from Unix.ml:
>
> let rec waitpid_non_intr pid =
> try waitpid [] pid
> with Unix_error (EINTR, _, _) -> waitpid_non_intr pid
>
> With a closed type, there is not much you can do to ensure that you
> catch the right type of exception here (matching on strings? seems
> much worse).

I'm one of those people that uses result everywhere + result monad where
the error case is a polymorphic variant.  This lets me get the value of
an open type with power of an exhaustive pattern match check.  No
strings needed.

>
> Note that, as there is no break keyword in the language, you tend to
> use exceptions for control flow to avoid rewriting your for loops to
> while loops.

This is exactly what monads and applicatives give you: a way to short
circuit computation when it's no longer needed.

>
> You can write some APIs without exposing exceptions, the same way that
> you can write an API without exposing a global hash-table.

I'm not sure what you mean here, I have not had to expose exceptions in
any APIs I've written.  I don't think they are bad APIs.

>
> Exceptions are just a tool, that allow you to work around some
> limitations / performance issues / make your life easier. Removing
> them is impossible at this point for compatibility reasons, so all you
> can do is avoid using them if it makes you sad (the same way you avoid
> using some parts of the language when you program in c++ / ecmascript
> / whatever language du jour).

My point is that I cannot avoid exceptions without being very defensive
in my code.  A dependency can always start throwing an exception and I
have no tool to help me find that automatically.

>
> Nathan
>
>
> On 20 October 2017 at 11:56, Malcolm Matalka <mmatalka@gmail.com> wrote:
>> I have a question in two parts:
>>
>> 1. Would this be a good idea? Why? (I'll describe why I think it is)
>>
>> 2. If it were a good idea, is it feasible to do?
>>
>> Full question:
>>
>> Despite exceptions being a part of the language, there is a trend in
>> many libraries to try to avoid using them.  While I cannot find it, I
>> recall someone (Daniel maybe?) saying that the standard API advice is
>> that exceptions should not cross API boundaries.
>>
>> The short reason for why people seem to want to avoid exceptions (which
>> I agree with) is that they side step the type system for helping you
>> understand if your code is correct and handles all situations the code
>> might experience.  Since the exn type is open, it means that one can add
>> any exception they want so it's not even known what exceptions you might
>> get ahead of time.
>>
>> Another aspect of exceptions, which might be more of my personal
>> experience, is that exceptions tend to be pretty useless after the
>> fact.  For example, forgetting to handle a Not_found exception is an
>> exercise in pain.  Maybe I'm just bad at this, but many exceptions just
>> aren't that useful.  End_of_file is another one that, IMO, makes the
>> program flow pretty awkward and if you have multiple files you're
>> reading from at the same time quite ugly.  I tend to use wrappers that
>> give me an option based API.  Maybe I just bad at solving these problems
>> though and I'm the problem.
>>
>> The consequence of this is that even though I put a lot of effort in my
>> code trying to avoid exceptions, I can never actually know that I have
>> succeeded unless I'm very defensive and wrap all foreign calls in some
>> exception handling code.  There are APIs for this, but if I mess up then
>> I'm in a bad spot.
>>
>> My proposal is that exceptions becomes a closed type and they reflect
>> what Java calls "errors", which are things your program logic should
>> generally not handle but can choose to if it wants to (I think we call
>> these failures in Ocaml).  The two specific exceptions I can think if
>> that should exist are: Assertion_failure and Out of Memory.  Another one
>> that I think might be nice but is open for debate is a
>> Not_implemented_failure, I use something like this often while building
>> a system.  I'm sure there are a few more that people can think of are
>> meaningful, but the point is these represent pretty bad situations that
>> the program logic shouldn't handle except in special situations.
>>
>> Thanks for reading,
>> /Malcolm
>>
>> --
>> 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