Proposal: Extensible exceptions

[Evan Laforge]

>> Incidentally, the Haskell standard libraries (although not the report)
>> also
>> implement exitWith in terms of an exception.  Personally, I think this is
>> a
>> great idea, as I'd rather not deal with two separate mechanisms for
>> cleaning up in unexpected cases (i.e. bugs or exceptions or being passed a
>> function that calls exitWith).
>
> As I said, in case of a bug, it is not possible to reliably clean up. That
> an error is encountered proves that your assumptions about your program were
> wrong, and so the assumptions about allocated resources are probably wrong,
> too. To pick up Chris Smith's perspectives, cleaning up would be the task
> for the next higher level, for which your error is only an exception - it
> has hopefully kept track of the resources you allocated.

How would the boundary where an error becomes an exception be defined?
 Would you have some catch error and rethrow as exception type
function which defines the next higher level?  In my experience, the
"level boundaries" depend a lot on the individual program, and are
fuzzy because there are big boundaries and small boundaries.  Which
ones you think of depend on how disciplined you're being and what
level the code is at.

Say I have (withFile something_broken).  I guess there's some kind of
cosmic-ray chance that the broken code could somehow close the file
itself and then withFile is in trouble (let's say close a file twice
has some dire consequence), but the chance is low enough that there
are bigger bugs to chase.  Does that mean withFile defines a level
boundary that can reliably clean up its broken callee?

It seems to me that there are lots of bugs that you can reliably clean up after.

> It seems that nobody except me is interested in handling specifically (up to
> a certain level) the exceptional cases that an IO action can lead to. If I
> see the type signature
>  getLine :: IO String
>  I have no idea, what kind of exceptions can occur. I even have to be
> prepared to get OpenGL exceptions. Even error codes in C are more
> informative in this respect. I would have to handle some exceptions which
> look reasonable to me, and use a catch-all or rethrow-all mechanism for the
> rest. Possibly the proposers of the extensible exception method like to rely
> entirely on catch-all or rethrow-all just like errors. Wouldn't
>  getLine :: ErrorT IOError IO String
>  be much clearer?

It think it would be interesting, though not really solving some big
problem I've been having, though sometimes problems are obvious only
in retrospect.  Is there an implementation to experiment with?

But...  isn't it out of the scope of this proposal?  And I'm not sure
how it fits in with the errors vs. exception distinction, or even what
the api for errors would look like.  A parallel set of throwError
catchError etc.?  Then it would just be a different kind of exception.