You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No, switching to std::runtime_error does not help, I still have unreported exception. And looks like the exception type has nothing to do with the issue: I set a debug breakpoint in
OK, I see. So the Python error has correctly been set by Boost.Python, but Python's own runtime then flags this as an "unreported exception". In other words, you could strip your code off all Boost.Python references, only using Python's own C API, and you'd still observe the issue.
Can you report this to the Python bug tracker ?
Oh, indeed, that looks sensible. Can you write a (minimal) test case to demonstrate the problem as well as that your proposed change fixes it ? That would make a great PR !
I just tried to fix it locally this way and it solved the problem. Well, I could try to create a test case and PR, but I'm quite new to boost libs testing infrastructure...
Had the same issue, boost::python was hiding the real exception with raised unreported exception. I applied the patch if (handle_exception(init_function)) return NULL; mentioned by @db4 and now the real exception is thrown.
Activity
stefanseefeld commentedon Dec 9, 2019
What happens if you replace
std::exceptionbystd::runtime_erroror some other more specific exception type ?db4 commentedon Dec 9, 2019
No, switching to
std::runtime_errordoes not help, I still haveunreported exception. And looks like the exception type has nothing to do with the issue: I set a debug breakpoint inpython/src/errors.cpp
Lines 48 to 51 in ac62db1
and verified that this catch case was executed.
stefanseefeld commentedon Dec 9, 2019
OK, I see. So the Python error has correctly been set by Boost.Python, but Python's own runtime then flags this as an "unreported exception". In other words, you could strip your code off all Boost.Python references, only using Python's own C API, and you'd still observe the issue.
Can you report this to the Python bug tracker ?
db4 commentedon Dec 9, 2019
Are you sure that's a Python problem? Maybe
python/src/module.cpp
Line 24 in 1727b67
should be replaced with
?
stefanseefeld commentedon Dec 9, 2019
Oh, indeed, that looks sensible. Can you write a (minimal) test case to demonstrate the problem as well as that your proposed change fixes it ? That would make a great PR !
db4 commentedon Dec 9, 2019
I just tried to fix it locally this way and it solved the problem. Well, I could try to create a test case and PR, but I'm quite new to boost libs testing infrastructure...
stefanseefeld commentedon Dec 9, 2019
OK, great. I'll see whether I can write a quick test.
db4 commentedon Jun 29, 2020
Hi @stefanseefeld
Any news on the issue? Are you still planning to create a test and finally commit the fix?
tdelame commentedon Nov 20, 2020
Had the same issue, boost::python was hiding the real exception with
raised unreported exception. I applied the patchif (handle_exception(init_function)) return NULL;mentioned by @db4 and now the real exception is thrown.twvd commentedon Feb 2, 2021
Also just ran into this problem.. Just bumping this issue to show it's still relevant and affects users.
Add a test case for issue boostorg#280
Fix issue boostorg#280
db4 commentedon Feb 3, 2021
I finally decided to stop waiting for something and create PR myself
Add a test case for issue #280
Fix issue #280