Re: [saxdotnet-devel] ErrorHandler arguments

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

Reply to self:


Karl Waclawek wrote:
 > On xml-dev there is a thread called "[xml-dev] SAXException, checked, buy why?".
 > The problem that came up is what to do when trying to pass recoverable
 > errors to the application? Alan Gutierrez thinks one is not allowed to use
 > error handler call-backs, but I think that maybe this is just a result
 > of underspecification. In any case, the objects passed to the error
 > call-backs are SAXParseException objects in Java, and ParseError objects
 > in SAX for .NET.
 >
 > I am thinking we should rename the class from ParseError to SAXError,
 > as errors from application code (as you might have in your content handlers)
 > are not really parse errors, and you should still be allowed to pass
 > them to the error handlers, to avoid throwing an exception.
 >
 > However, all members of ParseError (or SAXParseException ) are geared towards
 > errors that can occur when parsing an XML document (publicId, SystemId,
 > Line/ColumnNumber, etc.).

There is also the problem that SaxParseException has ParseError as member.
So, renaming ParseError gives cascading problems.

 > So, what to do?
 > Should we stick with the limitation that only parse errors can
 > be reported to the error handlers? Is that not rather limiting?

Maybe the right approach is to simply docoument a broader definition
of "parsing". One could say that in the context of SAX,

  "parsing" denotes any form of generating a stream of
   ContentHandler/LexicalHandler events that correspond
   to a well-formed XML document.

With that definition, a "parse" error could also be
an error in the underlying event generation when it
is not XML document based.

So, with giving "parsing" a broader definition
we also give ParseError a broader meaning.

Karl