[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

[Henning Thielemann]

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.