Proposal: Extensible exceptions

[Henning Thielemann]

On Sun, 6 Jul 2008, David Menendez wrote:

> On Sun, Jul 6, 2008 at 4:31 PM, Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
>>
>> On Sun, 6 Jul 2008, David Menendez wrote:
>>
>>>> data DivideByZero = DivideByZero deriving (Show, Typeable)
>>
>> Maybe I annoy you with my distinction of errors and exceptions, but I
>> consider DivideByZero a bad example for an exception, because it is more an
>> error (I see it is used in the extensible exception paper anyway).
>
> It's also in the current Control.Exception library.

There are many things wrong about Errors and Exceptions in the current 
Haskell library:
    http://www.haskell.org/haskellwiki/Exception
    http://www.haskell.org/haskellwiki/Error


> While dividing by zero or accessing an array out of bounds isn't the
> same as a file not existing, I'm not sure we need different mechanisms
> for dealing with them.

Yes! Because there is no need to recover from an error. Instead an error 
must be fixed by the programmer. The program cannot do this by itself. I 
consider recovering from an error like in a web-server a hack, like 
catching and recovering from an 'error' in IO is a hack, just like 
unsafePerformIO. I accept that we need a hack in order to tell the user 
"please send a bug-report to XYZ", but a hack should be called a hack, not 
"proper exception handling".

> 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! 
Handling errors is the task of Debugging, not that of Exception Handling. 
I suggest special variants of 'finally' and 'bracket' for bracketing bugs 
should be located below "Debug" in the module hierarchy.