|Jeremy Hylton : weblog : 2003-11-03|
Monday, November 03, 2003, 4:00 p.m.
Am I the only one who sees Python complain about WHY_RETURN with an exception set? The default Python installations on my system are all debug builds. They do a lot of error checking that is turned off by default, and run much slower as a result. They also find all sorts of interesting bugs.
One of the checks is for a return from the mainloop -- eval_frame() -- with an exception pending and a non-error why code. The variable why indicates why the block stock is being unwound. Possible values are WHY_NOT (no error), WHY_EXCEPTION (exception occurred), etc.
I hit several of these errors running the Zope 3 test suite today with CVS Python. The last time I saw this error message, Fred Drake and I found a bug in pyexpat.c -- from the checkin message:
Fix several bugs in handling of exceptions with trace function enabled. If the callback raised an exception but did not set curexc_traceback, the trace function was called with PyTrace_RETURN. That is, the trace function was called with an exception set. The main loop detected the exception when the trace function returned; it complained and disabled tracing.
It should be a fatal error for the mainloop to exit with an undetected error. On several occasions, I've noticed the error after it's too late to recover what went wrong. A core dump would be better.