Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Jose Iborra schrieb:
Folks,
I'm happy to announce a new release of control-monad-exception with monadic call traces, available in Hackage. Grab it now while it is still online!
Monadic stack traces are described in detail in a blog post [1].
In short, what this means for your code is the ability to generate errors like this:
500 Internal Server Error The CGI server failed with the following error: DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC "Testing RPO") in deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (108, 3) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (106, 20) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 33) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 30) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50, 9) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46, 11)
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?
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.
thomas.
2009/11/3 Henning Thielemann
Jose Iborra schrieb:
Folks,
I'm happy to announce a new release of control-monad-exception with monadic call traces, available in Hackage. Grab it now while it is still online!
Monadic stack traces are described in detail in a blog post [1].
In short, what this means for your code is the ability to generate errors like this:
500 Internal Server Error The CGI server failed with the following error: DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC "Testing RPO") in deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (108, 3) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (106, 20) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 33) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 30) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50, 9) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46, 11)
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?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 03/11/2009, at 14:24, Henning Thielemann wrote:
Jose Iborra schrieb:
Folks,
I'm happy to announce a new release of control-monad-exception with monadic call traces, available in Hackage. Grab it now while it is still online!
Monadic stack traces are described in detail in a blog post [1].
In short, what this means for your code is the ability to generate errors like this:
500 Internal Server Error The CGI server failed with the following error: DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC "Testing RPO") in deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17) deleteBenchmarkFromPK, NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (108, 3) deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (106, 20) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 33) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 30) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50, 9) cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46, 11)
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
cgiMain `catchWithSrcLoc` \loc e@SomeException{} -> outputInternalServerError [ "The Narradar CGI server failed with the following error:" , showExceptionWithTrace loc e]
gives you that kind of information. What you do with the stack trace, printing it (currently it is simply a list of Strings) or something else, is your choice. Thanks, pepe
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.
Henning Thielemann escribió:
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. I think you have overlooked a few things. First, not every developer knows each one of the lines in the code well enough as to see where a exception comes from, specially when you are not the author of that code.
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. You know, could you tell me when using head on an empty list is a
Of course, that wouldn't mind so much unless you see another thing, if we don't know which exceptions can be launched by a operation then you will get it on the upper frame and rendered unable to solve it. Use typed exceptions (as this library intends to) you may say. Ok, now we have another problem, the strange habit of coders to keep the exceptions they don't know/can't treat going up and up and up, until then usually hit the top frame and you are screwed. You can check some Java code (to see an example on how this happens) as some of these exceptional conditions are put on the method's signature. About detecting programming errors making them explicit on the type you can use IOized versions of the dangerous functions and use a special Exception type for them which would, usually, be caught at the top frame then showed. programming error and when it is a exception, I have seen both cases...
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.
Sorry for the confusion, I never meant that c-m-e can show stack traces for asynchronous exceptions. It can not. I used the head of empty list error to draw a simile of why you would like to have a stack trace. I do not share your opinion that monadic call traces are not of much use. Your example looks a bit conspicuous to me. Consider a web application using HDBC to interface with a database, where a SQLError can arise and there is no way to find out where it is coming from. The safe-failure package (not officially released yet, but an early version is available in Hackage) provides monadic versions of several partial functions in the Prelude. An applicative interface is available which can make programming with those much more palatable. That means you can in effect obtain a stack trace for a head of empty list error. I would like, as much as anyone else, to see stack traces available for pure Haskell code. There are others already pursuing that goal, but as the situation stands now, stack traces are available only through expensive program transformations which cannot be used in production code. And I don't believe that situation is going to change in the close future. In contrast, monadic call traces have a simple implementation model by extending the bind operation with source locations. They are available now through the MonadLoc preprocessor which is not tied in any way to c-m-e. And moreover, they are unexpensive, can be used in production code, and can make your life much easier in many, many cases. I'm not sure if I managed to dispel your doubts, if not perhaps you could make your points more clear. Thanks, pepe
On Sat, 7 Nov 2009, Jose Iborra wrote:
Sorry for the confusion, I never meant that c-m-e can show stack traces for asynchronous exceptions. It can not.
My post was not related in any way to asynchronous exceptions. It's just the everlasting issue of the distinction of programming errors and exceptions.
I'm not sure if I managed to dispel your doubts, if not perhaps you could make your points more clear.
I'm trying that for years now, repeatedly in this mailing list and on the Wiki: http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I don't know how I can make it still clearer. It's just like concurrency vs. parallelism - somehow related, but it is important to distinguish them.
On Sat, Nov 7, 2009 at 9:54 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sat, 7 Nov 2009, Jose Iborra wrote:
Sorry for the confusion, I never meant that c-m-e can show stack traces
for asynchronous exceptions. It can not.
My post was not related in any way to asynchronous exceptions. It's just the everlasting issue of the distinction of programming errors and exceptions.
I'm not sure if I managed to dispel your doubts, if not perhaps you could
make your points more clear.
I'm trying that for years now, repeatedly in this mailing list and on the Wiki: http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I don't know how I can make it still clearer. It's just like concurrency vs. parallelism - somehow related, but it is important to distinguish them.
And yet if I use library ABC, which I expected to be error-free, and it in
fact has a programming error, is this an error or an exception from my point of view? Based on the definitions you posted, I believe the correct answer is "error." However, I'd much rather have a way to recover from that kind of error if it's logical. For example, let's say that I'm writing a web browser in Haskell (it could happen). If there's an error in the HTTP library which causes it to die on certain types of headers, I'd much rather be able to tell the user sorry and let them continue browsing than to up and die with a "Prelude.head" message in their console. Michael
Excerpts from Michael Snoyman's message of Sat Nov 07 22:55:14 +0100 2009:
On Sat, Nov 7, 2009 at 9:54 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sat, 7 Nov 2009, Jose Iborra wrote:
Sorry for the confusion, I never meant that c-m-e can show stack traces
for asynchronous exceptions. It can not.
My post was not related in any way to asynchronous exceptions. It's just the everlasting issue of the distinction of programming errors and exceptions.
I'm not sure if I managed to dispel your doubts, if not perhaps you could
make your points more clear.
I'm trying that for years now, repeatedly in this mailing list and on the Wiki: http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I don't know how I can make it still clearer. It's just like concurrency vs. parallelism - somehow related, but it is important to distinguish them.
And yet if I use library ABC, which I expected to be error-free, and it in
fact has a programming error, is this an error or an exception from my point of view? Based on the definitions you posted, I believe the correct answer is "error." However, I'd much rather have a way to recover from that kind of error if it's logical.
For example, let's say that I'm writing a web browser in Haskell (it could happen). If there's an error in the HTTP library which causes it to die on certain types of headers, I'd much rather be able to tell the user sorry and let them continue browsing than to up and die with a "Prelude.head" message in their console.
If there is an "error" raised by the HTTP library on some headers, then this is a bug (a programming error), and so by using it your program is buggy too. However I would say that in this case wrapping the buggy function into safely-failing one is a valid temporary hack. A way to help distinguishing errors and exceptions would be to have pre and post conditions on function (as in "Static Contract Checking for Haskell"[1]). For instance head would have the following contract: {-# CONTRACT head :: { xs | not (null xs) } -> Ok #-} head :: [a] -> a head [] = error "head: empty list" head (x:_) = x When there is a pre-condition (or a contract) like here, it is a programming error to give an empty list to head. This means that checking if the list is empty must be done before the call. It has to statically deductible from the call site. If you write a function and cannot prove that you will not call head on the empty list then either you check before calling, or you use a safe-head function or you add a pre-condition to your function. [1]: http://www.cl.cam.ac.uk/~nx200/ -- Nicolas Pouillard http://nicolaspouillard.fr
participants (6)
-
Henning Thielemann -
Jose Iborra -
klondike -
Michael Snoyman -
Nicolas Pouillard -
Thomas Hartman