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.
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)
or
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. :-(
--
Brad Clements, [EMAIL PROTECTED] (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
http://www.wecanstopspam.org/ AOL-IM: BKClements
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml
