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