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