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

On Tue, Apr 05, 2005 at 12:40:01PM -0400, Stefan Seefeld wrote:
Daniel Veillard wrote:

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

Fine ! Though I would use some kind of polymorphism to provide this
functionality to any language binding, not just python. What about
setting up some global (but protected) variable (akin to an internal 
that callback wrappers may use to indicate failure ?

  I'm objecting to this because global variables then generate the question
of what happens when multiple threads raise errors, etc ... Unless there
is a clear need at the library level I would keep this a Python only 

Make this a 'void *' normally set to 'NULL', and then abort the normal
processing if it is != NULL. Wrapper code may then tunnel any data through 

  and what happens when 2 threads use libxml2 python bindings. Parsing of A
fails because parsing of B generated and error. No this is more complex than
that, really.


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]