except effect about monad-classes

[UnkindPartition]

Throwing exceptions is done using throw. For handling exceptions there are two options:

• runExcept from C.M.C.Run, which is the same as runExceptT (but with a different name)
• let them reach the IO layer and turn them into ordinary runtime exceptions

The situation with functions like catch and withExcept is subtle. The user might get an impression that she's just mapping exceptions, but in reality she's also moving them from one layer to another, which may affect how exceptions interact with other effects.

So yes, my intention was to use runExcept to make the semantics a bit more explicit. But if you have compelling use cases for these other functions, I am open to reconsider.

[ibotty]

i am frequently using withExceptT to map from one type of exception to another.
say given an ExceptT m InternalException a i want to wrap it in a sum type data MyException = InternalE InternalException | SomeOtherExceptionwithwithExceptT InternalE`.

what do you think about making catch and a type changing mapException part of the type class? that way it won't move from one layer to another. of course the order of layers might still change.

btw. in extensible-effects the moral equivalent to withExcept is called rethrowExc. perhaps that makes it more clean.

[UnkindPartition]

Making mapExcept part of a type class addresses my concerns. Only I'd like it to be a separate class (cf. MonadReader/MonadLocal). MonadMapExcept? One of the reasons to do so is that it'll require an additional MFunctor constraint, if I'm not mistaken.

Same for catch. I guess you'll need MonadTransControl to lift it automatically.

[ibotty]

I am aware that catch and thus withExcept need additional constraints. I'll send a pull request within that week i suppose.

Thanks for being supportive.