Re: Re: ErrorHandler questions

David Megginson wrote:
> On Fri, 07 Jan 2005 13:26:12 -0500, Karl Waclawek <[email protected]> wrote:
> 
> 
>>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).
> 
> 
> The pipeline model wasn't fully established until after SAX was, so we
> hadn't really considered that problem at the time.  I think the answer
> is that ErrorHandler should have been more flexible, but it really was
> designed just for parse exceptions.  Perhaps it would be worthwhile
> developing an extension handler for recoverable application errors,
> but it might be hard to standardize.

To some degree one can argue that an error detected in the content
handler can also be a parsing error. This would be the case when the
content handler validates the well-formed input for additional
constraints, especially those that cannot be expressed through
existing schema languages.

Let's consider the case of validation layered on top of a non-validating
SAX parser. This has to be done through that layer's content handler.
But currently there is no standardized way for the validator to generate
ErrorHandler call-backs, since SAX does not provide for a getter/setter
(property) to pass a reference to the error handler.

As far as application errors are concerned:
The API needs to concern itself only with what would be common to
all errors. Consumer and producer of the error "object" passed
to the handler could both agree on subclassing it appropriately
for communicating app-specific information (and behaviour).

> 
> How would a third-party content handler in a pipeline get a reference
> to the error handler?  I might be missing something obvious.

Well, the content handler component would need to be aware that
such an error reporting interface exists, whether it is ErrorHandler
or another specification. It would then need to expose a property
to set a reference to the error handler instance.
Ideally, one would add an ErrorHandler (or similar) property (get/set)
to the ContentHandler interface itself.

Karl


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
List: sax-devel, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel