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-perfectly-acceptable-thanks-very-much/ [2] http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
