Proposal: Extensible exceptions

[Isaac Dupree]

Henning Thielemann wrote:
>> If your code divides by zero, you still want any "finally" or 
>> "bracket" clauses to get called before the program terminates.
> 
> A program which divides by zero is broken and must be fixed. A program 
> which divides by zero but cleans up a bit, is still broken and must be 
> fixed. Cleaning up may make things better, but may also make things 
> worse!

it can make things worse?  (When cleanup is somehow significantly 
dependent on the buggy part of the code that led to the error? How often 
does that happen??)  I appreciate how bugs in Haskell are much 
better-behaved than many languages.  For finally-clauses, they should be 
called equally whether there is a legitimate IO exception (if you 
believe in such a thing; they're even in Haskell98 in a form), or a 
buggy-program exception, and there is no good reason to fail to call 
'hClose' just because some pure code in some part of the program divided 
by zero.  Especially because of Haskell's laziness, that division by 
zero might have been lexically called somewhere before opening the 
handle, but be evaluated after it's been opened and before it's been closed!

This way, if my IO uses 'bracket' when it should, a bug in one part of 
the code is less likely to cause obscure bugs in entirely unrelated IO 
parts of the code.  Exceptions are designed to be ubiquitous and 
always-possible... especially when you consider asynchronous exceptions.

In fact it's possible to use these exception capabilities to isolate 
different parts of the program from each other's bugs so the whole thing 
doesn't crash: although that's when it becomes much closer to your 
assessment of "a hack".  That "hack" still can be quite useful, of 
course, if you agree with the Awkward Squad paper.  It depends whether 
modularity of bugs is part of your worldview?-- I'm glad Linux (and all 
other modern OS) isolates different processes' address spaces using MMU!

-Isaac