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

["WebShark" <webshark ono com>]

----- Original Message ----- 
From: "Stéphane Bidoul" <stephane bidoul softwareag com>
To: "'Chris Anderson'" <christop charm net>; <xml gnome org>
Sent: Sunday, September 28, 2003 11:17 PM
Subject: RE: [xml] Re: XML libs (was Re: gconf backend)


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

=====================================
http://www.3xtl.com