Proposal: Extensible exceptions

[Henning Thielemann]

On Mon, 7 Jul 2008, Yitzchak Gale wrote:

> Henning Thielemann wrote:
>>  Then there should be new modules that strictly separate between error
>> handling (they should be located under Debug) and exception handling (they
>> should be under Control.Monad).
>
> I would prefer all exceptions - whether or not they are errors -
> to be handled using the same mechanism. The distinction
> between what you call "exceptions" and "errors" can be reflected
> in the hierarchy of Exception objects.

Exception handling is more frequent than error handling. Error "handling" 
(should be better called "error hiding" or "bug reporting", because you 
can really handle errors only by fixing them) will occur at the very outer 
level of a program, as last resort. If you do error hiding more frequently 
you invest the time at the wrong place. You better invest it in more error 
prevention. This can be done at best with the type system, and the 
Extensible Exception as it stands, fools static type checking by hiding 
the actual Exception type by some type extensions. This design looks very 
wrong to me.

>> Exception handling should be done with an
>> ErrorT monad transformer...
>> This should be implemented on top of existing IO...
>
> Unfortunately, that is not possible currently. There are
> primitives, such as "bracket", that do not support this.

I don't see the problem. Current 'bracket' would be used for bracketing 
current IO code, new 'bracket' would be used to bracket new ErrorT based 
IO code. Then we add a function which allows conversion from ErrorT IO to 
IO by converting exceptions and then we can start replacing IO by ErrorT 
IO from the inner of the libraries.