Exceptions do not cause Backtraces

[GoogleCodeExporter]

When an exception is raised in a callback, a backtrace is not printed and the 
program does not stop.

I expect that upon an exception being raised in a callback the exception should 
be passed all the way up to where loop() is called on a loop.

Original issue reported on code.google.com by thomas.burdick@gmail.com on 19 Jul 2010 at 8:52

[GoogleCodeExporter]

This is not a bug, it's a feature :-).

quote from the callback attribute documentation:
"As a rule you should not let the callback return with unhandled exceptions. The
loop 'does not know' what to do with an exception happening in your callback
(might change in future versions, if there is a general consensus), so it will
just print a warning and suppress it. If you want to act on an exception, do it
in the callback (where you are allowed to do anything needed, like logging,
stopping/restarting the loop, ...)."

Imagine you have a server (a loop) with hundreds or thousands of connections 
(watchers). If one of those raise an exception, you don't want the server to 
stop serving the other connections (or do you?). Unfortunately there is no 
other way than stopping the loop if you want an exception raised.

That said, I'll try and add an option to the loop to stop on all exceptions, 
that might make developper's life easier (next release should be in 
september/october).

Comments/ideas/...?

thanks for the report

malek

Original comment by lekma...@gmail.com on 20 Jul 2010 at 9:02

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I have a semi-hacked version of this for myself, but I would greatly appreciate 
you adding an exception handling option to Loop.loop() that does one of the 
following...

unloops
prints backtrace
prints simple error
prints nothing (ignores all errors)

by default the printing simple errors would probably maket he most sense as 
thats what it does now.

Its hard to find bugs with that though!

Original comment by thomas.burdick@gmail.com on 24 Aug 2010 at 7:36

[GoogleCodeExporter]

> unloops
> prints backtrace
> prints simple error
> prints nothing (ignores all errors)
Why the last one? isn'it a little bit dangerous?

As it is I'm working on this (and other improvements to pyev) these days.

What I can easily do in C is add a 'debug' option to the Loop that will unloop 
and print a backtrace if set to True, if set to False (default) it will only 
print a backtrace (instead of a warning (which will consume the terminal's 
scrollback buffer faster though)).
Can you live with that?
Is 'debug' the right keyword?

And, while we're here, can you think of any other issue that if resolved would 
make using pyev easier?

As a side note, you know how easy it is to write what you ask in python, right?

Thanks for your help, really, since I work alone on this, it's sometimes hard 
to put myself in other people's shoes, so I really welcome any form of 
criticism. That can only lead to a better pyev.

malek

Original comment by lekma...@gmail.com on 26 Aug 2010 at 7:27

[GoogleCodeExporter]

I wouldn't mind helping out with this, but subversion makes that hard to do.

Original comment by thomas.burdick@gmail.com on 26 Aug 2010 at 4:57

[GoogleCodeExporter]

Hi Thomas,

sorry for the delay, I got caught up with something else.

> I wouldn't mind helping out with this, but subversion makes that hard to do.
I'd love that, but why is svn a problem? (I guess I could switch to Mercurial.)

Anyway, I have a new version of pyev sitting on my comp. I'll upload it to 
trunk today or tomorrow. I'll welcome reviews, suggestion for improvement, etc.
It is in a lot of ways different from the previous versions and is based on 
libev cvs (so don't expect a release before libev-4.00 is out).

What's missing:
- documentation (I'll handle it, as I have now some experience with sphinx, 
it'll need proofreading though)
- examples (if you can come up with interesting use case...)
- tests, I'd love pyev to have a test suite (that won't be easy as it will have 
to involve multiprocessing corner cases).
- win32 support? (I'm still not sure of this)
- anything you might come up with... 

Thanks for your help

malek

Original comment by lekma...@gmail.com on 6 Sep 2010 at 7:00

[GoogleCodeExporter]

Mercurial would make it easier simply because I can commit commit commit and 
not have to make it work, I really use dvcs as a big fat undo for myself, I 
don't mind using subversion its just not as easy :-)

I'm not too interested in win32 support.

Documentation would be very good, perhaps I should get cranking on some sphinx 
docs.

Examples would also be good, I don't mind writting those at all :-)

A test suite would be really nice, written in python I would presume?

I'm thinking it would be nice to have a layer on top of pyev itself, something 
I've been working on slowly but surely, to make it simpler to use in python for 
the purpose of writting a socket server (not the only thing pyev can do but one 
likely use)

see http://bitbucket.org/bfrog/whizzer

I think your right, ignoring all errors would be bad. It would be nice to have 
a google group or something instead of a bug tracker to discuss things.

Original comment by thomas.burdick@gmail.com on 11 Sep 2010 at 9:51

[GoogleCodeExporter]

I tried the debug flag in 0.6, it works great. This issue really is fixed at 
this point it seems.

Original comment by thomas.burdick@gmail.com on 30 Sep 2010 at 3:33

[GoogleCodeExporter]

fixed in upcoming 0.7.0

Original comment by lekma...@gmail.com on 28 Feb 2011 at 12:39

• Changed state: Fixed