exceptions API (Was: deprecating Error class, which Was: Proposal: add handleError to mtl))

Edward Kmett ekmett at gmail.com
Thu Jun 6 15:22:21 CEST 2013

On a somewhat related note, I've started but not yet released an
'exceptions' package based on some work from Mark Lentczner, after he
encouraged me to explore the design space with an eye towards inclusion in
the platform because some packages like CGI need something like
MonadCatchIO-transformers, but GHC HEAD removed block and unblock, so the
MonadCatchIO-transformers API is broken.

It doesn't fall into the scope of the mtl as it relies on the extensible
exceptions mechanism and so needs ExistentialQuantification, but it
provides a generalization of the Control.Exception API that lifts it over
monad transformers along with a pure untagged exception-handling monad.


I was going to sound folks out about what improvements they wanted to see
in the API over this weekend at Hac Phi, but I suppose I can throw that out
to the larger libraries list as well, given the current discussion.

The haddocks for the development version are available here:



On Thu, Jun 6, 2013 at 7:00 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

> On Thu, 6 Jun 2013, Roman Cheplyaka wrote:
>  * Henning Thielemann <lemming at henning-thielemann.de**> [2013-06-06
>> 12:14:10+0200]
>>> On Wed, 5 Jun 2013, Ross Paterson wrote:
>>>  On the subject of ErrorT, I wonder if it's time to deprecate the Error
>>>> class.
>>> Since I think ErrorT gives the wrong association with the 'error'
>>> function, I would prefer to give up the Control.Monad.Trans.Error
>>> module entirely and start a new module Control.Monad.Trans.Exception.
>> ... which would give the wrong association with exceptions (in the
>> Control.Exception sense). I don't see how this is an improvement.
> It's the better association and it is already mentioned in the module
> description of Control.Monad.Trans.Error:
> "This monad transformer adds the ability to fail or throw exceptions to a
> monad."
> Nonetheless, you may suggest another module name. Independent from the
> name of a new module, I would suggest to deprecate the Error name instead
> of removing something from the Error module.
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130606/629003ef/attachment.htm>

More information about the Libraries mailing list