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) > > 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. :-( clearly it's not trivial. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
