David Megginson wrote:
> On Fri, 07 Jan 2005 11:32:10 -0500, Karl Waclawek <karl@...> wrote:
>>1) Is it legal for an application's content handler to
>> call-back on the error handler?
> That is an excellent question, and one that I had never considered. I
> suppose that it is allowed, since it's not explicitly forbidden, but
> it does make a bit of a mash of encapsulation (the content handler is
> forced to hold or be able to obtain a reference to the error handler).
> Also, it is possible that many existing SAX apps assume that only
> XML-related errors come through ErrorHandler.
My reason for posting this message comes from a thread on xml-dev
called "SAXException, checked, buy why?". One of the problems discussed
was that ErrorHandler allows error processing without throwing an exception,
but if ErrorHandler is only legal for the parser to call, then there is
no *standard* way for the content handler to communicate recoverable
error events to the application, especially if the content handler
is not under application control (like in some third-party pipeline).
>>2) Related to previous ContentHandler message:
>> If a SAX event stream can be legally generated from other sources
>> than parsing an actual XML document, is then the definition of
>> the SAXParseException as argument for ErrorHandler call-backs
>> not a little narrow?
> That falls out from the first one. If ErrorHandler is only for XML
> parsing errors, then presumably there's no problem; if you start using
> it for application errors, things get trickier.
That's one reason.
The other one is that the event generator may not be a SAX parser,
so strictly speaking, there might not be parse errors, document
locations, system identifiers, etc.