RE: [xml] Beta release of 2.6.0beta2



On Fri, Sep 26, 2003 at 11:34:37AM +0200, Stephane Bidoul wrote:
IMHO, the per context callbacks are fine.
The per thread callback for global errors can cause
problems when a library (or  python module for instance)
is using libxml. Indeed when that library wants to catch
global errors, it must register it's own handler, therefore
overriding handlers that may haven been set by the main
application or other libraries.

  A lot of errors can occur outside of the context of parsing a
resource too. How do you handle them then ?

That's my point: the callbacks mechanism is fine
(and necessary) when you have a parser context,
but I think we could benefit of a per thread getLastError
mechanism for errors not related to a parser context.

  Can you provide a concrete proposal ?

Hum, how about a simple
const xmlChar *xmlLastErrorMessage
per thread global in globals.h

Inside libxml, instead of calling xmlGenericError directly,
you could call a function that sets xmlLastErrorMessage AND
calls xmlGenericError.

As I understand, whenever xmlGenericError is called to report
a non-parser-context-related error, the API also returns
an error status (NULL, -1). [The exception is debugging messages
but that could be handled separately.]
So the client code can simply check xmlLastErrorMessage whenever
such a function returns an error status:

XmlDocPtr doc = xmlNewDoc("1.0");
if (NULL == doc)
{
   fprintf(stderr,"Error creating a new document:
%s\n",xmlLastErrorMessage);
}

Do we need anything more complicated?
Error codes, maybe, but I'd say it's a different topic,
that would need to apply to the callback-based
error reporting too, thus requiring all new error
callbacks APIs.

-sbi




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