Erik de Castro Lopo | 5 Jun 05:04 2013

Proposal: add handleError to mtl

Hi all,

I would like to propose the following convenience function (with
implementation) for the mtl library:

    handleError :: MonadError e m => (e -> m a) -> m a -> m a
    handleError = flip catchError

which follows the handle function from Control.Exception.Base:

    handle :: Exception e => (e -> IO a) -> IO a -> IO a

Like the handle function, handleError allows the handling of
exceptions to be expressed in a more natural way, turning:

    catchError
        ( do
             mumble
             something
             mumble
        )
        handler

into:

    handlerError handler $ do
             mumble
             something
             mumble

(Continue reading)

Edward Kmett | 5 Jun 19:50 2013
Picon

Re: Proposal: add handleError to mtl

Sure. I can see merit to consistency with base in this regard. 

I would like a version of it in transformers monomorphized to the particular ErrorT monad though as well for
consistency. Does that mean we'd want a liftHandle to avoid doing a lot of flipping with liftCatch?

I maintain mtl though, not transformers, so any action on adding it there would have to go through Ross.

Sent from my iPad

On Jun 4, 2013, at 11:04 PM, Erik de Castro Lopo <mle+hs <at> mega-nerd.com> wrote:

> Hi all,
> 
> I would like to propose the following convenience function (with
> implementation) for the mtl library:
> 
>    handleError :: MonadError e m => (e -> m a) -> m a -> m a
>    handleError = flip catchError
> 
> which follows the handle function from Control.Exception.Base:
> 
> 
>    handle :: Exception e => (e -> IO a) -> IO a -> IO a
> 
> Like the handle function, handleError allows the handling of
> exceptions to be expressed in a more natural way, turning:
> 
>    catchError
>        ( do
>             mumble
(Continue reading)

Ross Paterson | 5 Jun 22:23 2013
Picon

Re: Proposal: add handleError to mtl

On Wed, Jun 05, 2013 at 01:50:01PM -0400, Edward Kmett wrote:
> Sure. I can see merit to consistency with base in this regard. 
> 
> I would like a version of it in transformers monomorphized to the particular ErrorT monad though as well
for consistency. Does that mean we'd want a liftHandle to avoid doing a lot of flipping with liftCatch?

For the monomorphic version, it's probably best to keep these lifts to a
minimum, and use flip on liftCatch.

On the subject of ErrorT, I wonder if it's time to deprecate the Error class.
Henning Thielemann | 6 Jun 12:14 2013
Picon

deprecating Error class (Was: Proposal: add handleError to mtl)


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. You could 
deprecate Error class and ErrorT type and stay in the version range 0.3.*.
Roman Cheplyaka | 6 Jun 12:55 2013

Re: deprecating Error class (Was: Proposal: add handleError to mtl)

* 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.

Roman
Henning Thielemann | 6 Jun 13:00 2013
Picon

Re: deprecating Error class (Was: Proposal: add handleError to mtl)


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.

Gmane