Proposal: Extensible exceptions
lemming at henning-thielemann.de
Mon Jul 7 09:09:55 EDT 2008
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.
More information about the Libraries