[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Change by Gregory P. Smith : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Andrew Svetlov added the comment: 'catch (boost::python::error_already_set e)' is equal to `except BaseException as e:` In Python, blind catching base exception is dangerous, the code should re-raise it usually. The same is true for boost::python usage. > how would it tell the difference

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Zac Bentley added the comment: For context (copied from the linked GitHub issue), this has affected at least two OSS projects: https://github.com/apache/pulsar/issues/11823 https://github.com/tbodt/v8py/issues/45 The proposed alternative ("PyErr_Fetch, then PyErr_Display, then

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Zac Bentley added the comment: Irit, the documentation is clear. However, the problem is that the presence of StopIteration in the exception global during async return time causes very unexpected behavior. If, during async return time (in the linked issue, I do this in a boost-python

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

Irit Katriel added the comment: Zac, the documentation for PyErr_Print [1] states that it clears the error indicator. This is akin to handling the exception. Was this your intention? If you want to print the exception without clearing it, I think you would probably need to call PyErr_Fetch,

[issue45033] Calls to PyErr_PrintEx in destructors cause calling async functions to incorrectly return None

New submission from Zac Bentley : If an object's destructor contains native code which calls PyErr_PrintEx, and that object's refcount drops to zero as the result of an async function returning, the async function incorrectly returns None. I first identified this behavior while using