Re: [boost] [Python] Improved exception handling for Python embedding

Subject: Re: [boost] [Python] Improved exception handling for Python embedding
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-01 17:21:03

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_transporting_data.html

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/