>
> On Tue, 13 Nov 2007, Bill Janssen wrote:
>
> > This (in functions.cpp) looks wrong. You're creating an instance of
> > ThrowableType, but saying that it's of type JavaError when you call
> > PyErr_SetObject().
> >
> > Bill
> >
> > PyObject *PyErr_SetJavaError(jthrowable throwable)
> > {
> > PyObject *err = t_Throwable::wrapObject(Throwable(throwable));
> >
> > PyErr_SetObject(PyExc_JavaError, err);
> > Py_DECREF(err);
> >
> > return NULL;
> > }
>
> No, this code gets python to raise an error of type JavaError whose
> error argument is the actual java throwable instance, wrapped.
>
> What you see is two layers of wrappers:
> 1. Throwable(throwable)
> wraps a C++/JNI wrapper around the actual java throwable
> 2. t_Throwable::wrapObject(...)
> wraps the CPython Throwable type around the C++/JNI wrapper so that
> one can make calls on it from python (such as getJavaException())
>
> Once can then call getJavaException() on that JavaError instance to retrieve
> the java stack trace from the actual java throwable:
>
> try:
> java(blah)
> except JavaError, e:
> print e.getJavaException().printStackTrace()
>
> Andi..
But I still have the problem reflected in the stack trace with GDB:
the "value" being extracted is not of the Python type JavaError (it's
of the Python type "Throwable"), and doesn't have the method
"getJavaException", while the "exc" *is* of type JavaError. Either
the code in PyErr_SetJavaError() isn't correct, or the code in
throwPythonError() isn't correct.
PyErr_SetObject() basically just stores the three values you give it
in three thread-global slots; it doesn't create a new instance of type
"exc" and somehow assign "value" to a slot in that instance.
Bill
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
