CODEWITHSUNDEEP
haskellmonad-transformers
John F. Miller
John F. Miller

Reputation: 27217

Transition from ErrorT to ExceptT

A recent cabal install upgraded my version of transformers from 0.3.0.0 to 0.4.1.0. With this upgrade came depreciation warnings about ErrorT.

The documentation is not clear is this just a renaming or is there a functional change? Why was this change made?

Upvotes: 14

Views: 844

Answers (2)

Joe Hendrix
Joe Hendrix

Reputation: 41

There is a change in the semantics.

ErrorT e m expects that e implements the Error class in its Monad instance. This allows the implementation of fail for ErrorT e m to throw an exception:

fail msg = ErrorT $ return (Left (strMsg msg))

In contrast, ExceptT does not make any such restriction. Instead the implementation of fail for ExceptT e m calls the exception in the underlying monad m:

fail = ExceptT . fail

I prefer ErrorT's behavior since it allows me to catch any instance where fail is called by code over a generic monad. In any case, it's important to review your code before blinding renaming ErrorT to ExceptT.

Upvotes: 4

J. Abrahamson
J. Abrahamson

Reputation: 74344

There is a functional change. ErrorT demands that the e type be a member of the Error type class—for example, consider its Monad instance constraints. This is fairly arbitrary and certainly not needed for the functionality of ErrorT.

ExceptT lifts this restriction.

The renaming was introduced in order to create a more smooth upgrade pathway. People who currently use and depend upon the Error constraint in their ErrorT stacks should not have to change code. People who'd like to use the strictly more general ExceptT module can freely choose to do so. At some point the ErrorT module may be removed.

Upvotes: 15

Related Questions