Re: [xml-dev] SAXException, checked, buy why?

[Karl Waclawek <karl@waclawek.net>]

Alan Gutierrez wrote:

>>>   http://www.saxproject.org/apidoc/org/xml/sax/ErrorHandler.html
> 
> 
>>I am not sure the docs really exclude its use in content handlers,
>>they just don't mention it. But they also don't mention that the
>>source for content handler events could be something other than a
>>SAX parser, in which case the question comes up whether one is
>>allowed to use ErrorHandler, and where to register its instance.
> 
> 
>>It might be more a question of underspecification than a question
>>of prohibited use?
> 
> 
>     What if the type of error is not a SAXParseException? I'm
>     already feeling uncomfortable calling everything a SAXException.

Yes, but that is the trouble with checked exceptions.
Personally I think it would have been better to pass an object
of some non-exception type to the error handler call-backs.
The class could have been named SAXError, or SAXStatus.

Actually, in SAX for .NET we have decided to pass a non-ecxeption
class to the error handlers, but we are still calling it ParseError
- so maybe we should rename it to SAXError, to be more generic.

>     The method signatures seem to drive home the talk of the parser
>     calling the handler.
>     
>     Also, SAX is simple, and mature. By now the docs should have
>     fleshed out. The omission is what I'd like to go by.

Well - in our western society - what is not explicitly forbidden, is allowed. :-)

>     I'd have to assume that enough of the other filter/handler
>     authors take the same interpretation and that ErrorHandler is
>     not going to give me the chance to rectify an error during an event.

I would say that is true, but the reason for it is probably
that most programmers don't really think too much about
error recovery.

>     I'm thinking that the filtering concept was not designed into
>     the original SAX, and that error interception was not considered.

Could be.

>     (Many SAX content handlers I've used connect directly to the
>         parser and serialize, build a document, etc. So this is
>         probably enough for that soft of application, and SAX filtering
>         is the sort of thing that folks expect to be a one off.)
> 
>     Still, you seem to feel that an error observer is the way to go,
>     for interception of errors in the event stream, when your using
>     someone else's content handler or content filter.

The point is that if a content handler does not call back on error handler,
then its author should be aware that there is an implicit limitation
in her/his design. And if the author really considered it necessary to
provide for error recovery, then she/he would probably provide for a documented
way to do so, using ErrorHandler or some proprietary API.
That's just life in programming, I guess.

As an example for another possible approach, one could have
defined all handlers to accept a "Status" object as additional
parameter (based on some abstract class definition).
Each handler in the chain could inspect and modify this object,
allowing information to pass up and down.
The application could register a concrete subclass instance
of that Status class with the event generator, to provide for
custom processing of errors.

Karl