On Mon, Oct 18, 2010 at 2:14 PM, Paolo Losi <paolo.l...@gmail.com> wrote: > 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 :-)
The typeclass itself is simple. It's the *instances* that are complicated. At least I find InvertIO to be not much more complicated on the instance side. >> 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... The point here is that we want to treat these things very differently. Just take a look at the runHandler code in the Yesod.Handler module: runtime exceptions need to be wrapped up in an internal server error, whereas "Left" values from the ErrorT get "case"d on. I understand that all of this could be done with extensible exceptions, but that's really just taking something which is currently explicit and type-checkable and making it implicit. It really does seem to me to be a typical dynamic-versus-static issue. Michael _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
