wxPython uses SWIG, so does PyLucene. Maybe the solution I developed for the very same problem in PyLucene can be reused in wxPython ?
It goes as follows. In PyLucene, Python code calls gcj-compiled Java (C++) code via SWIG-generated glue code. That C++ code can in turn call back into Python via python's C API in a number of situations. If an error occurs in that Python code, NULL is returned by Python to the calling C++ (compiled java) code. Every such call to Python has its return value tested and a Java/C++ PythonException is thrown when NULL is returned. That PythonException is then caught at the inbound call boundary crossing, where NULL is returned again to Python for it to properly report the Python error raised earlier.
In PyLucene every call from Python to Java (C++) is bracketed by the following code:
try {
PythonThreadState state; // release the Python GIL
$action // the actual call to the Java/C++ API
} catch (org::osafoundation::util::PythonException *e) {
// a Python error was raised
// in Python callback code
return NULL;
} catch (java::lang::Throwable *e) {
// a Java exception was thrown
// in Java code and a corresponding
// Python error is raised
PyErr_SetObject(PyExc_JavaError,
jo2pr_type(e, "java::lang::Throwable *"));
return NULL;
}and every call from Java/C++ to Python is written as (for example):
{
PythonGIL gil; // reacquire the GIL before calling back into Python // construct Python arglist for Python call
PyObject *pyReader = jo2pr_type(reader,
"org::apache::lucene::index::IndexReader *");
PyObject *pyFieldName = j2p(fieldName); // call into Python
PyObject *pysdc = callPython(*(PyObject **) &pythonSortComparatorSource,
"newComparator", pyReader, pyFieldName, NULL); // release Python arglist objects
Py_DECREF(pyReader);
Py_DECREF(pyFieldName); // if Python error raised during call
// throw PythonException
if (!pysdc)
throw new org::osafoundation::util::PythonException(); // else return value
...
}It seems that wxPython does the same: we call into it from Python via SWIG, it then calls back into Python for such things as event handlers. If wxPython verified the return value from a Python API call and threw a C++ exception, that exception could be caught at the inbound call boundary crossing and NULL could be returned to Python signalling that an error was raised and needs to be reported (with a valid Python stack trace as a bonus).
Andi..
On Wed, 13 Apr 2005, John Anderson wrote:
I also spend a several days tracking this down this exact problem a few weeks ago. Robin says it is now probably possible to have Python exception travel through C++, but that implementing it would be a big job. Currenly Python exceptions are caught and printed on stderr when the enter C++. As an alternative, I was thinking it would probably pretty easy to generate a dialog when running the debug version of Python, which would allow developers to find problems and testing the debugging version of Chandler not to loose asserts.
John
Bryan Stearns wrote:
Yesterday I tracked down another bug where an exception was hidden by wx:
- User caused wx to dispatch an event from C++ into our Python code (clicking something)
- Our python code threw an exception
- No exception handler caught the exception before the stack reentered C++, so it was never caught or logged
There was a brief in-person discussion about this problem last week, but I don't think any solution was discussed... so I'm bringing this up for discussion here:
- Is there a way wx can be fixed to handle this? (ultimately, its C++ code owns event dispatching - when it catches an exception from our Python code, should it return to our Python code which calls it, causing the program to exit, but maybe in a way where the exception could be logged?)
- Or is there something we should put in our code to deal with this (in _all_ the places where C++ code calls us? Ick!)
- Or is this not really a problem?
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
