Re: [xml] enhancing the error handling API

[Daniel Veillard <veillard redhat com>]

On Tue, Mar 18, 2003 at 12:03:25PM -0500, Stefan Seefeld wrote:
> Aleksey Sanin wrote:
>
> > You can! You do not want to change/remove the existing error functions.
> > Which means that old error function simply must calls the new ones.
> > Of course, some parameters (file, line, etc.) will not be set but this will
> > help to do migration slowly.
>
> By the way, I'm not convinced that a single generic error handler is
> such a good idea. May be we can classify the type of error to make the
> handlers a little less generic but more 'typed'. For example 'file' and
> 'line' attributes seem to be relevant only in the context of file
> parsing.

  Wrong, they are relevant in XInclude, in XPointer, in XSLT, in XPath
errors within XSLT, or even in the tree API ...

> What about xpath syntax errors (say) ? Or (I'm coming from C++,
> you'll notice) stream based input, i.e. when there is no notion of 'file
> name' ?

  It's perfectly okay to have file == NULL, or some arguments not used.
No need to be tied to C++ to have generic I/O layer, as soone as you
have a pointer to a node or a document or an Input/Output buffer a 
relevant file or resource name can usually be extracted and returned.

> I think the approach to capture all that in a single generic handler is
> fundamentally flawed.

  You can have per parser context, I would keep that. For everything
else at least the signature of an error callback will be unified.
  The thing which annoys me the most with your mail is:
      - it doesn't suggest anything
      - the exact same points can be raised with the existing infrastructure
  So what's the point ?

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/