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.