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

[Malcolm Matalka <mmatalka@gmail.com>]

David Allsopp <dra-news@metastack.com> writes:

> Malcolm Matalka 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.
>
> Without wishing to open old debating wounds too much, the argument of exceptions as errors tends to come down as to whether the thing
> signalled by an exception is truly exceptional. Not_found, for example, in some scenarios is as unexpected or impossible as
> Invalid_argument. Historically, they're (ab)used for performance reasons, but some of the overhead of that is being addressed in
> flambda. Note that for some arguable design mistakes - e.g. End_of_file, you can use exception matching to get around this, e.g.
>
> match input_line ch with
> | data -> ...
> | exception End_of_file -> ...
>
> which means that the old pattern
>
> let data = try Some (input_line ch) with End_of_file -> None
>
> is only needed if you need to compile with OCaml < 4.02
>
> If you haven't come across it, https://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm is an interesting piece of older research around dealing with handling exceptions.
>
> What your proposal does overlook slightly is the use of exceptions for actual flow control. See for example, an oldish post of Alain
> Frisch's at https://www.lexifi.com/blog/static-exceptions. However, uses of exceptions like this may at some point be subsumed by Algebraic
> Effects which are being worked on by various people, mostly with multicore OCaml in mind. There's lots of links to that in
> https://github.com/ocamllabs/ocaml-multicore/wiki as well as other literature elsewhere online.
>
> HTH,
>
>
> David 

Thank you for the response and reading material.