Re: [xml] Error handling with the XmlReader API

[Daniel Veillard <veillard redhat com>]

On Tue, Jan 14, 2003 at 11:54:22AM +0100, Stéphane Bidoul wrote:
> >    Well the C reader implementation uses a parser context. the same
> > code for the general case can probably be reused nearly as-is except
> > for the freeing part. Or a completely different approach can 
> > be attempted
> > (and exception would be fine).
>
> Actually, I was first thinking of a way to expose an xmlreader error
> handling API at the C level. Then I could add it at the python level.
> Today, it's not possible, because the xmlParserCtxt is not exposed
> (and even if it was, it would not be very clean to use it for that
> purpose, IMHO).

  for purely the error handling, I agree it's not "clean"

> How about?
>
> typedef void (*xmlTextReaderErrorFunc)(xmlTextReaderPtr ctx, const char *msg);
> int xmlTextReaderSetErrorHandler(xmlTextReaderPtr reader, xmlTextReaderErrorFunc f)
>
> Or?
>
> const char *xmlTextReaderGetLastError(xmlTextReaderPtr reader);
> void xmlTextReaderClearLastError(xmlTextReaderPtr reader);

  Hum, one of the key point of the error handler over SAX is that
the user code keep the control of the processing flow. The LastError
code seems better in this respect. However the C# binding is based on
exception and in general it's a good thing for error handling. For C
that's not possible. So let's keep a non-callback interface for error
handling too at that level.
  There is a few technical problems with the approach you suggest,
basically the error callbacks from the parser will not be synchronous
to the current node of the parser, hard to avoid technically. When doing
a Read() a 512 byte blob is parsed, and errors are reported at that 
point. Second problem is that there will be multiple error callbacks
at the SAX level for a single logical error, that can probably be handled
relatively cleanly though. Last when parsing a chunk multiple errors
may be raised during what's viewed from the reader interface as a single
step, so getting only the last message may prove too limited in practice.

  It's not that simple. The second interface seems more in-line with
the reader design, but the first interface would be simpler to implement
and probably more accurate.

  I can't really select one as being better than the other at this point,
what other people think, you included ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/