[C++-sig] Re: Calling a python function from C++ (from Jeff Holle)

[Jeffrey Holle]

Given what the name of this exception, I assume there is a source of 
information to obtain useful information about it.
To this end, I've dug a bit into the Python C API and found the added 
the following to my code example:

   catch (error_already_set& x) {
	PyObject *err_type,*err_value,*err_traceback;
	PyErr_Fetch(&err_type,&err_value,&err_traceback);
         cout << "something bad happened" << endl;
     }

While I see that err_type and error_value are not null pointers after 
the call to PyErr_Fetch, I don't know what to do with either to get at a 
useful message.
Can anybody provide any hints?

Jeffrey Holle wrote:
> I've explored whats actually going on some with my debugger and now see 
> what is being thrown.
> It is "error_already_set".  This is a trivial object (it has no 
> attributes at all), and isn't much better than "catch (...)".
> However, its name implies something.  Is there a meaningful error 
> message set somewhere else that can be accessed within the catch clause 
> of "error_already_set"?
> 
> Jeff Holle wrote:
> 
>>>
>>>
>>>> An underlining concern I have is error handling.  When
>>>> PyImport_ImportModule fails, a NULL pointer is returned.
>>>> Seems like the underlining machinery in "handle<>" is intolerant of
>>>> this. 
>>>
>>>
>>>  
>>>
>>>
>>> What makes you say that?
>>>
>> You are correct about the success in compiling your much cleaner 
>> example, and it works :-) , but has a flaw.
>>
>> When I hide the needed python script, the call to 
>> PyImport_ImportModule returns NULL.
>> When this occurres, both your example and what I had created, but 
>> commented out throws something because I can catch it with 
>> "catch(...)".  I don't however know how to be more specific.  Any 
>> hints?  Whatever it is, it doesn't inherit from "exception".
>>
>> If I was operating on windows, I would anticipate it was a "structured 
>> exception", or whatever Microsoft calls their propritary stuff.  Don't 
>> know of the equivalent on linux though.  Without the "catch (...)", 
>> the command line program exits with "Aborted".