[
Lists Home |
Date Index |
Thread Index
]
* Karl Waclawek <karl@waclawek.net> [2005-01-03 11:37]:
> Alan Gutierrez wrote:
>
> >>What makes this different from the ErrorHandler interface
> >>already specified in SAX?
> > public interface ErrorHandler {
> > public void error(SAXParseException exception)
> > throws SAXException;
> > public void fatalError(SAXParseException exception)
> > throws SAXException;
> > public void warning(SAXParseException exception)
> > throws SAXException;
> > }
> > It is meant to respond to errors in parse, not errors in content
> > handling. If content handler authors were to adopt it for use as
> > a means to intercept genral errors, they'd be going against the
> > documented use.
> > 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.
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.
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'm thinking that the filtering concept was not designed into
the original SAX, and that error interception was not considered.
(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.
--
Alan Gutierrez - alan@engrm.com
- References:
- Re: [xml-dev] SAXException, checked, buy why?
- From: David Megginson <david.megginson@gmail.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Uche Ogbuji <uche.ogbuji@fourthought.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Alan Gutierrez <alan-xml-dev@engrm.com>
- Re: [xml-dev] SAXException, checked, buy why?
- From: Karl Waclawek <karl@waclawek.net>
|