erikd
commented
7 years ago It doesn't compose well.
I'd like to see examples of where you see that, because in the code we have at work ExceptT composes very well. It does so because we have a library of ExceptT combinators to help with the composition.
Catching errors in the monad gives a false security that exceptions have been caught, since there are also IO exceptions and pure exceptions.
The fact that all your exceptions aren't being caught isn't a good argument for doing away with ExceptT. Instead, you should be improving your code to make sure all exceptions are caught and converted to RpcErrors.
For an example of some of our code calling createProcess and trapping exceptions in ExceptT, see:
https://github.com/ambiata/mafia/blob/master/src/Mafia/Cabal/Process.hs#L41-L60
I'd like to remove the Rpc monad and just throw IO exceptions
That would be reasonable if there is only one or two layers of software. I've been spending time chasing exceptions in some of our code. Our code is called mismi, which sits on top of amazonka, which sits on top of http-conduit which sits on top of http-client-tls which sits on top of tls which sits on top of network. The problem I've been chasing is that (very) occasionally we have been getting an exception that bubbles up to the top and kills a complex multi-threaded program.
kolmodin
The Rpc monad is defined as
which is problematic. It doesn't compose well. Catching errors in the monad gives a false security that exceptions have been caught, since there are also IO exceptions and pure exceptions. Currently no other feature are needed from the monad except for exceptions (no pun intended).
I'd like to remove the Rpc monad and just throw IO exceptions, and document properly what method will throw, and on best practices.