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

[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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[tphyahoo]

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 <lemming@...>:

> 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@...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[pepeiborra]

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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[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.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[klondike-4]

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.

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.
> 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...





_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[klondike-4]

Luke Palmer escribió:

> On Fri, Nov 6, 2009 at 6:54 PM, klondike
> <klondikehaskellcafe@...> 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.



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[pepeiborra]

>
>
>> 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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Henning Thielemann]

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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Michael Snoyman]

On Sat, Nov 7, 2009 at 9:54 PM, Henning Thielemann <lemming@...> 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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Nicolas Pouillard-2]

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@...> 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@...
http://www.haskell.org/mailman/listinfo/haskell-cafe