This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients pitrou, vstinner
Date 2008-08-20.15:44:51
SpamBayes Score 3.1122614e-05
Marked as misclassified No
Message-id <1219247094.29.0.551349290316.issue3611@psf.upfronthosting.co.za>
In-reply-to
Content
I retract what I said above. PyErr_SetObject() and friends only change
tstate->curexc_* variables, not tstate->exc_*.

The former (tstate->curexc_*) contain the current, pending (uncaught)
exception state of the thread. The latter (tstate->exc_*) contain the
exception currently handled by an "except" statement in Python code. 

So, theoretically, there is no way calling PyEval_CallObject() can
change tstate->exc_value:
- if it raises an exception or calls code that raises an exception
without catching it, the exception ends up in tstate->curexc_*, not in
tstate->exc_*
- if it calls code that raises an exception /and catches it/, exception
stacking means the exception should be discarded after the end of the
"except" block and the last tstate->exc_* values restored.

Of course, there may be bugs in the implementation of the above. The
best way to find out would be to have a small snippet of Python code
reproducing the problem. :-)
History
Date User Action Args
2008-08-20 15:44:54pitrousetrecipients: + pitrou, vstinner
2008-08-20 15:44:54pitrousetmessageid: <1219247094.29.0.551349290316.issue3611@psf.upfronthosting.co.za>
2008-08-20 15:44:53pitroulinkissue3611 messages
2008-08-20 15:44:52pitroucreate