[C++-sig] Re: throw_error_already_set()
Niall Douglas
s_sourceforge at nedprod.com
Thu Dec 18 12:19:33 CET 2003
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17 Dec 2003 at 14:51, David Abrahams wrote:
> I think you're misinterpreting things. Internal errors in BPL are
> always handled with assert(), and never with exceptions.
What about the famous "Attempt to return dangling %s to object of
type: %s" error? This is generated by setting the python exception
state and throwing error_already_set.
> > Is it possible to modify BPL to do this
>
> I don't think so. Well, OK, we could provide a hookable error
> handler. I'd worry how it'd interact with threads, though.
Surely almost all the time inside BPL is spent with the GIL held?
Well, except in my case as I've modified BPL to release the GIL when
entering C++ code.
> Why don't you just look at the python error state at the catch
> point?
Because that breaks my nested handled exception framework. I've added
run time code to allow destructors to throw exceptions without
killing the process via terminate() (it still fatally exits, just
through a controlled fashion - I really think the ISO C++ standard is
wrong here - it means a tiny hard-to-find-during-testing mistake will
kill your entire process which does not aid writing robust code).
Anyway the entire basis of this requires all compatible exceptions to
be derived off the base FXException class.
> > or am I relegated to wrapping every BPL call with a
> > try...catch(error_already_set &)?
>
> I think you need to re-evaluate your EH strategy. You must be
> embedding Python. You should handle Boost.Python errors in the same
> place where you handle other exceptions in your program.
I'll be writing code later on where C++ code will run some python
which performs operations with C++ objects wrapped via BPL ie;
multiple layers of embedding. I also want one python interpreter to
call code in another interpreter seamlessly and new threads to
automatically handle python being called.
> > I did notice there only appears to be one place where
> > error_already_set is caught within BPL - therefore couldn't I
> > literally just do a find & replace (or better, a #define
> > throw_error_already_set FXPython::int_throwPythonException() so I
> > don't have problems with merging new releases)
>
> No comment. Modify your private copy of the Boost.Python sources at
> your peril (or not).
Well it's already modified to unlock the GIL so I was going to merge
the BPL DLL into the TnFOX.pyd DLL. I can't see any licensing
problems with that as it's made very clear where the code originally
comes from.
The good news about all this is that it's already extremely easy to
embed python snippets into C++ with TnFOX, and once I have these
other small problems fixed it's about to get much easier. v0.5 will
be out shortly!
Cheers,
Niall
-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
iQA/AwUBP+GNR8EcvDLFGKbPEQIGcgCgnb1mZUWYyre+Il2MPEOTp6cJY3MAoOJt
rCqsYnv7I9hVKRafSRjb29IA
=IS/+
-----END PGP SIGNATURE-----
More information about the Cplusplus-sig
mailing list