On Thu, 14 Oct 2010 12:01:59 +0200, Michael Snoyman
[...] which I believe is a flawed design in the MonadCatchIO-transformers package. Here are my thoughts on this and what I think needs to be done to fix it.
[...]
Try running the code with each version of go uncommented. In the first two, "sequel called" gets printed. However, in the third, it does not. The reason is short-circuiting: if we remember from the definition of finally, there are two cases we account for. If an exception is called, catch addresses it. If not, we assume that the next line will be called. However, in the presence of short-circuiting monads like ErrorT, that line of code will never get called!
Yes. That is the behaviour I would expect. There are two kinds of exceptional values in, for instance, 'ErrorT e IO a': • IO exceptions, in the "underlying monad" 'IO'; • error values of type 'e', in the monad transformer 'ErrorT e'. The MonadCatchIO instance for ErrorT deals with the first kind only. Catching IO exceptions, and cleaning up after them, is what MonadCatchIO was invented for. I feel that I should not decide for all users how these two layers of exceptions should interact; keeping the MonadCatchIO instance oblivious to the underlying monad as much as possible seems like the safest/most general thing to do. Meanwhile, I can see why you would want 'finally' to also catch the ErrorT errors, in your example, and circumvent the short-circuiting. However, I'm not convinced that this is always the right (expected, most useful, ...) behaviour. Maybe I just need more convincing :-). By the way: my apologies for not being more responsive and proactive in this matter. At the moment, I have very little time for my haskell endeavours. But more importantly, my maintainership of MonadCatchIO-transformers is mostly coincidental. (I found the MonadCatchIO-mtl code very useful, except I needed it for 'transformers' instead of 'mtl'. So, I forked it (at that time, only the cabal file needed editing), and put it on hackage.) If you feel that as maintainer I'm more of a roadblock than helping you make effective use of this library, then perhaps you should take over maintainership. Regards, Arie