RE: [xml] Re: XML libs (was Re: gconf backend)

[Chris Anderson <christop charm net>]

On Sun, 2003-09-28 at 17:17, StÃphane Bidoul wrote:
> > > For instance, assume we have library A that uses libxml2, 
> > > and library B that uses libxml2 too.
> > > Both need to catch global error messages, but they don't
> > > know about each other. They can't both register their own
> > > global xmlGenericError at the same time, right?
> > >
> > > The last error mechanism is only a proposal to work 
> > > around this without requiring far reaching changes to 
> > > the APIs. 
> >
> > I save the current handler and set my own handler while I use libxml2,
> > then restore the old handler when I am done.  
>
> Sure. But that can become quite complex in libraries
> with many entry points and possibly callbacks into client code.

Yeah, even more so if you want to swap out some of the other global
context like the allocation routines.  A global context structure ptr is
useful here.

> > I think the last error
> > mechanism would be similar, you'd clear the error before calling and
> > check it after leaving the api.  
>
> No need to clear it before: the last error is not a way to detect
> that an error occured, it's just a way to know which error it was,
> when libxml2 tells you that something has failed.

True.

> > The global handler is really 
> > a logging
> > function... if you have multiple contexts going, it's nice to 
> > be able to
> > tag the error with the context in the log because even though 
> > the error
> > might not have anything to do with the context (out of memory), you
> > still want to know which context failed so that you can resubmit it.
>
> Hum, IMHO it's more than a logging function. Sometimes you need the error
> message elsewhere than in a log file, and the global handler is
> the only way to get that message back from libxml2 ATM.

I mentioned logging because of the printf-like functionality.  That's
really why it synchronous -- there's more information about the error at
the point it occurred -- I like that.