Proposal: Extensible exceptions
isaacdupree at charter.net
Sun Jul 6 18:32:57 EDT 2008
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
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!
More information about the Libraries