Re: [xml] using "raise" in Python error handler callbacks

On Tue, Apr 05, 2005 at 10:18:08AM -0400, Stefan Seefeld wrote:
Hi Daniel,

Daniel Veillard wrote:
On Thu, Mar 31, 2005 at 07:57:04PM -0500, Stefan Seefeld wrote:

I don't think this is quite accurate. Think about python as a high-level
API to a C runtime. If the outer and the inner python runtimes are
the same, there is certainly a way to pass the necessary information 
(i.e. ultimately just preserve the exception state from the callback).

 If you know how to do it, I take patches. I don't know how to do it in
the general case, i.e. without changing all C APIs to have an extra 
to carry those informations. And changing the public C APIs is not 
Again I take patches !

The information about the exception state is lost when the generated
'libxml_xmlTextReaderRead' function unconditionally returns an integer.
Here is a quick hack for libxml2-py.c:9017

    c_retval = xmlTextReaderRead(reader);
    if (PyErr_Occurred())
      return NULL;

The 'PyErr_Occurred()' function will return 1 since the (python) error
callback raised an exception that was not yet dealt with.
With the above hack, the example of the OP indeed generates a stack trace
(a TypeError as the string in the 'raise' expression is malformed).

However, things are more complex than that, since xmlTextReaderRead will
potentially call the (python) callback multiple times, erasing the exception
state from former calls.
Right now libxml2 seems to assume that (error) callbacks can't fail 
I'm not sure whether there is anything to do here.

  So PyErr_Occurred() check should be done when C call python at the,
return point, right ? 
I think this occurs only in a few places within python/libxml.c which is
not autogenerated. So hacking this might be possible.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]