[C++-sig] Re: throw_error_already_set()

[Niall Douglas]

-----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-----