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

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.


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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]