RE: [xml] Beta release of 2.6.0beta2

["Stephane Bidoul" <stephane bidoul softwareag com>]

> 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