![](https://secure.gravatar.com/avatar/72ee673975357d43d79069ac1cd6abda.jpg?s=120&d=mm&r=g)
Guido van Rossum wrote:
But there are still quite a few situations in NDB where an uncaught exception prints a baffling traceback, showing lots of frames from the event loop and other async machinery but not the user code that was actually waiting for anything.
I just tried an experiment using Python 3.3. I modified the parse_request() function of my spamserver example to raise an exception that isn't caught anywhere: def parse_request(line): tokens = line.split() print(tokens) if tokens and tokens[0] == b"EGGS": raise ValueError("Server is allergic to eggs") ... The resulting traceback looks like this. The last two lines show very clearly where abouts the exception occurred in user code. So it all seems to work quite happily. Traceback (most recent call last): File "spamserver.py", line 73, in <module> run2() File "/Local/Projects/D/Python/YieldFrom/3.3/Examples/Scheduler/scheduler.py", line 109, in run2 run() File "/Local/Projects/D/Python/YieldFrom/3.3/Examples/Scheduler/scheduler.py", line 53, in run next(g) File "spamserver.py", line 50, in handler n = parse_request(line) File "spamserver.py", line 61, in parse_request raise ValueError("Server is allergic to eggs") ValueError: Server is allergic to eggs -- Greg