Re: [saxdotnet-devel] ErrorHandler arguments

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
> Karl,
> 
> What did you think about my idea for a supplemental Exception handler 
> interface? This could be grafted on without much change to the 
> fundamentals of the API.

I must have missed this. Could you explain it again?

> Otherwise, might I suggest making ParseError 
> descend from SAXError and making SAXError more generic. Then you could 
> simply use "is" or a cast to get the more complete parse error 
> information when applicable.

If you look at SAX more closely, a lot of stuff that
now is based on the assumption of "parsing an XML document"
could be re-defined more generically in terms of a well-formed event sequence.
That could be a lot of work.

For instance: ParseError.Throw() has this code:
   throw new SaxParseException(this).
So, if we change to SAXError, we should first make "Throw()"
a virtual method and add it to SAXError where it throws a SaxExcpetion.
Then we need to add a SAXError member to SaxException and and a corresponding
constructor. We have to remove it from SAXParseException (as it already exists
in the base class) and change its constructor.
Then we need to override ParseError.Throw().
Then we have to modify the ParseErrorImpl class accordingly.
And then we still haven't covered all areas where "parsing"
should be generalized.

Yes, I could introduce a SAXError class, but what if we
just document that "parsing" really does not mean that
there has to be an underlying XML document? Any well-formed
event stream is "parsing".
Then we could leave ParseError and even SaxParseException as is.
The Locator related fields in ParseError (and SaxParseException)
are alread optional (they can return null or -1), even in Java.

It would be a simple documentation change.

Karl