Thanks for you reply, Michael. See inline ... On Mon, Oct 18, 2010 at 11:21 AM, Michael Snoyman
As an haskell newbie, I've got some questions on this matter.
Is it using ErrorT instead of extensible exeptions really necessary? I've read your comment stating that we cannot pass function arguments to Exceptions because of the Show class constraint. But is that really limiting? Wouldn't your use case (e.g. HTTP redirection in Yesod) be implementable with extensible exceptions?
I would guess that the rule of thumb would be not to mix extensible exception and ErrorT whenever it is possibile.
I've quickly read your post on inverting transformer stacks and, from my newbie point of view, I feel that the extra complexity isn't worth the gain.
I'm not sure why you think inverting the ErrorT monad is more complicated than MonadCatchIO: they're both doing basically the same thing. The difference is that MonadInvertIO does this generically for a whole class of functions, and therefore does it right.
I could have written MonadCatchIO, I could not have written InvertIO :-)
Anyway, it *is* theoretically possible to use extensible exceptions anywhere you would use ErrorT, but there's always a runtime hit in using runtime exceptions. Also, it's a difference in philosophy: coming from a language like Python or Ruby, it may feel natural to use exceptions for these kinds of cases. In Haskell, we try to make exceptions respect their name, and only use them in exceptional circumstances.
Is the performance penalty of using runtime exception so high? I would sacrifice some bits of performance for a more consistent error reporting / flow control. For the argument that Exceptions are for exceptional cases I'm totally with David MacIver [1]. I perfectly see the point of using ErrorT, but not when you need to handle runtime exceptions as well. As an haskell newbie I think that _THIS_, error handling strategies, is the single most troublesome point where some consistency (at least as a best practice) is really needed. I had hopes that extensible execptions could clarify the issue raised by [2] at least in "new" code... Thank again Paolo [1] http://www.drmaciver.com/2009/03/exceptions-for-control-flow-considered-perf... [2] http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-erro...