On 1 Aug 2014 at 12:27, Emil Dotchevski wrote:
Boost.Python throws boost::python::error_already_set exceptions whenever calls to embedding functions such as boost::python::import() or boost::python::exec() fail.
This exception is just an empty class. It does not provide any information on the error which occurred on the Python side. It is not even a standard exception in the C++ sense.
This is by design. It very intentionally does NOT inherit from std::exception in order to avoid a RTTI lookup.
I took a quick look -- if I read the code right, the Boost Python exception types don't even derive from std::exception. I can't think of any reason why that's done, you're right that it should be fixed.
Secondly, I suggest using BOOST_THROW_EXCEPTION to throw. This would allow arbitrary information to be attached to the exception object, not only at the throw site but also at a later time. See http://www.boost.org/doc/libs/release/libs/exception/doc/tutorial_transporti...
With respect to the above as it was clearly meant to be helpful, this is the wrong place to ask for help with Boost.Python - very few here know anything about that library now that Dave has left. Go to the Python C++ SIG mailing list (https://www.python.org/community/sigs/current/cplusplus-sig) where you'll get accurate help. There is about one person there nowadays who replies, but he'll reply with experience. I'd also strongly suggest that you search the archives of that mailing list. It contains a ton of very useful info on why Dave made the design choices he did. Almost all of them were correct - Dave is an outstanding engineer. (BTW error_already_set means "go ask the python runtime for the error". It is very deliberately and intentionally held separate from the C++ exception system for lots of very good reasons, some of which are summarised at http://misspent.wordpress.com/2009/10/11/boost-python-and-handling-pyt hon-exceptions/ and don't include the fun of dealing with C++ => Python => C++ => Python => C++ exception handling, but also because a lot of the time you really don't want python exceptions to propagate into C++, and an empty state non-polymorphic type exception is cheap to catch and throw away for those scenarios, plus if you do wish to extract the python exception state you doing it by hand is going to be no slower than BPL doing it for you, and you can code around the gotchas like exception throws during module loads etc). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/