Boost logo

Boost :

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

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
( 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
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).


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at