Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
klondike schrieb: Henning Thielemann escribió: 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 programming error and when it is a exception, I have seen both cases... The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
klondike schrieb: Now comes the time when I have to show you that not every exception could be handled, IE a file not found exception when looking for the config file can be fatal and force the program to stop. But what if this is on a library? How do you suggest that the programmer knows that the File Not Found exception is due to the lack of that config file, specially when the code is badly (or not) documented. A library function that reads a config file may declare to be able to throw the exception File not found, or it may introduce a new exception Could not read Config file with an extra field for the reason, why the file could not be read. This way you can construct a call stack that helps the user (and not the programmer). Then the message reported to the user might be: Program could not be started, because Config file could not be read because Config file does not exist in dir0, dir1, dir2 but the exception handler may also decide to use a default configuration instead or ask the user, how to proceed. Anyway, such a call stack for the user requires different information than a call stack for programmer for debugging. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) Out of curiosity, how would you classify an error that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? Cheers, Greg On Dec 7, 2009, at 2:23 AM, Henning Thielemann wrote: klondike schrieb: Henning Thielemann escribió: 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 programming error and when it is a exception, I have seen both cases... The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Gregory Crosswhite schrieb: Ah, I had been meaning to read your article, so I appreciate you posting the link to it a second time. :-) Out of curiosity, how would you classify an error that results from a perfectly fine program, but ill-formed user input, such as when compiling a source file? I thought I just used this as an example in the article ... ill-formed input is clearly an exception, since it is not the fault of the compiler developer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Henning Thielemann escribió: A library function that reads a config file may declare to be able to throw the exception File not found, or it may introduce a new exception Could not read Config file with an extra field for the reason, why the file could not be read. This way you can construct a call stack that helps the user (and not the programmer). Then the message reported to the user might be: Program could not be started, because Config file could not be read because Config file does not exist in dir0, dir1, dir2 but the exception handler may also decide to use a default configuration instead or ask the user, how to proceed. Anyway, such a call stack for the user requires different information than a call stack for programmer for debugging. The point here being? My point has been As programming errors are something common lets at least make them easy to solve. If you make such a fancy stack the programmer is still clueless about where the unhandled exception was generated and can't solve it. There is also another important point here which is error recovery, it's not unusual to see on servers and other high availability programs a last barrier which would show info on the error and then restart/resume the server as if nothing has happened. Following your definition, now we have exceptions, not errors, as they are expected, though they made some harm to our transaction. Henning Thielemann escribió: The case of (head []) is simple: It is a programming error, since the precondition for calling 'head' is that the argument list is non-empty. The caller of 'head' is responsible to check this. If the list comes from user input, then the program part that receives this list from the user is responsible to check for the empty list before calling 'head'. If there is no such check, this is a programming error, and it will not be possible to handle this (like an exception). Before you answer: What about web servers?, please read on the article I have written recently to sum up the confusion about errors and exceptions: http://www.haskell.org/haskellwiki/Error_vs._Exception Well I got used to going back to the previous state without crashing when I got a precondition violation due to user input. Though I assume that was asking a bit too much of Haskell. Of course crashing the whole program as default behaviour is a better way to solve the problem. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
2009/12/07 klondike klondikehaskellc...@xiscosoft.es: Well I got used to going back to the previous state without crashing when I got a precondition violation due to user input. Though I assume that was asking a bit too much of Haskell. It's too much to ask of partial functions. If you want to state your preconditions and rollback in an appropriate monad, that's of a horse of a different color. Of course crashing the whole program as default behaviour is a better way to solve the problem. If you're not working in a side-effecting or sequential subset of the language, you can't really expect to have a consistent notion of the state before the crash. It's a declarative, lazy language, after all. Consider, also, that a crash is just one of the problems you get with bad input; another one is infinite loops. As Henning Thielemann points out in his wiki article, you can't expect to catch those as they don't throw exceptions or cause any errors! You need to validate the input or use a timer in that case. Relying on the program to crash in a timely manner if something is wrong with the input is not a strategy that is going to go the distance. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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
lemm...@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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
Luke Palmer escribió: On Fri, Nov 6, 2009 at 6:54 PM, klondike klondikehaskellc...@xiscosoft.es wrote: 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. 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. You sound like you are expecting something that works exactly like the imperative exception handling mechanisms you are used to, and are not willing to accept anything else. No, I sound like I am expecting programmers comming from the imperative world to do ugly things, maybe because I once was one. This strange habit of programmers is simply bad practice, and leads to just as brittle code as no exception handling, except that you get inexplicable error message boxes with OK buttons instead of crashes. You might as well just put the whole program in a catch block in IO and bail with something noncomittal. Now comes the time when I have to show you that not every exception could be handled, IE a file not found exception when looking for the config file can be fatal and force the program to stop. But what if this is on a library? How do you suggest that the programmer knows that the File Not Found exception is due to the lack of that config file, specially when the code is badly (or not) documented. IMO, Haskell's typed exceptions (via eg. explicit-exception) *are* the way to go. They keep the number of exceptional conditions that can occur in a body of code small -- if some code has many exceptional conditions, it forces you to *compose* them somehow, to come up with a more precise idea of what your code is doing and how it can fail. Yeah, the thing comes when you get the same kind of exceptions from different places, you need a way to tell them appart. If you are just blindly passing exceptions up from the code below, the interface to your code is getting more and more complex. With typed exceptions, the types are reflecting the complexity of the interface (which is precisely the purpose of types). Well, it's not like blindly pass exceptions up but more like passing exceptions I don't know how to handle up. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
On Sat, Nov 7, 2009 at 9:54 PM, Henning Thielemann lemm...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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
[Haskell-cafe] 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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 lemm...@henning-thielemann.de: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
