On Tue, 3 Nov 2009, Jose Iborra wrote:
On 03/11/2009, at 14:24, Henning Thielemann wrote:
Sure, this is a nice functionality. But isn't it about debugging, not
exception handling? Internal Server Error means to me, the server has a
bug, thus we want to know, how to reproduce it, thus the stack trace.
For handling expected irregularites, what exceptions are, you would not
need that, right?
This is about error handling and reporting. Catching an exception does
not tell you where the exception comes from, in the same way that a
"head of empty list" error does not point at the source of the error.
You need a stack trace to know that. So the output above, generated by a
regular exception handler
Thomas Hartman tphyahoo at gmail.com Tue Nov 3 08:59:50 EST 2009
When using happstack, I find it really annoying to get a Prelude.head:
null list error (or similar) in my web browser window because somewhere,
some library used something unsafe -- and of course, since this is
haskell, no stack trace.
if c-m-e can offer benefits around this, I would be very interested in
adopting it.
That's what I meant with my post: Programming errors (like "head []") are
not handled by control-monad-exception. As far as I understand,
control-monad-exception makes _exceptions_ explicit in the type
signatures, not programming errors. Why and how would you make possible
programming errors explicit in the type? But for exceptions (e.g. "file
could not be found") a detailed stack trace is not of much use. It seems
again to me, that mixing of (programming) errors and exceptions is going
on, and I assumed that the purpose of control-monad-exception is to
separate them in a better way.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
