Re: [Classpathx-xml] ContentHander errors getting to an ErrorHandler?

[David Brownell]

>        I consulted
> the O'Reilly book and found the following quote which validates the current
> AElfred2 behaviour:
> 
> 'when a SAX handler throws an exception, parsing stops immediately.   The
> exception passes through the parser and is thrown by XMLReader.parse().'

It's actually SAX behavior, not just AElfred2 ... :)


> The rest of that section of the book then hints that SAX handlers can (and
> should?) use the ErrorHandler as a centralized location for error-handling.  
> But
> how can I do that if (a) the parser doesn't passed the errors to my 
> ErrorHandler
> and (b) a ContentHandler doesn't have a natural link to the ErrorHandler to 
> use?

As for (a), have a look at tip # 6 in this article:

    http://www.xml.com/pub/a/2001/12/05/sax2.html

Short answer is that you shouldn't throw exceptions _except_ in the
ErrorHandler.

As for (b) this is something you just deal with in SAX:  when you set things
up, you set things up ... and you can't rely on back-channels to communicate
much information.  The XMLReader does expose the ErrorHandler (and for
that matter, every other handler, feature, or property!) that you need.  That's
a win over SAX1, where you had to remember everything yourself.


> Do I have to build framework code so that all of my ContentHandlers know their
> ErrorHandler?  If that was the desired behaviour, it seems strange to me that 
> a
> ContentHandler couldn't automatically get told about its ErrorHandler.

Yes, build your framework code with an explicit "set things up" stage,
and lots of things work more smoothly.  You can focus things around
the XMLReader, which exposes every handler (etc) rather than having
every interface learn about every other interface.

As for "the desired behavior", I view that as just one particularly powerful
way to assemble the standard interfaces ... not the only way.  It's like a
LEGO set ... there isn't a single "desired way" to use a particular block.

- Dave