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

On Wed, Apr 06, 2005 at 03:10:30PM -0400, Brad Clements wrote:
On 5 Apr 2005 at 16:48, Daniel Veillard wrote:

  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.

Somewhat unrelated to error handler callbacks..

My code uses this code when working with libxslt in Zope:
  libxml2.setEntityLoader(_Resolver) # this is a process-wide change, 

and wish it were per-thread or even per-document instead of being global.

  The callback gives the parser context, usually it is sufficient to
differenciate what document is being loaded. Might be a bit trickier at
the python level but still possible.

But anyway, with respect to the entityloader function itself. If an entityloader generates 
a python exception, libxml2 doesn't propogate that error back through the system to 
"cancel" the current conversion or parsing process.

The last time I looked at the source, libxml2 considered an exception to be the same as 
returning "None", which means "I can't handle this, use the default loader".

When looking at handling python exceptions, it would be nice to try to figure out how to 
propogate the exception condition back-up through the calling chain so that 

    doc = libxml2.parseDoc(srcXML)


    result = style.applyStylesheet(doc,stylesheetArgs) 

exposes the exception created in the EntityLoader callback..

I tried looking through the source last year, but it's a bit more complicated than I had 
first imagined, so I gave up. :-(

  clearly it's not trivial.


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]