Re: More on SAX Exceptions

[David Brownell <david-b@pacbell.net>]

> > In all cases, rule of thumb:  if the handler throws an exception, the
> > parser should be passing it through unaltered.
> 
> Just to clarify, I think you mean the exception gets propogated up to the
> caller of parse(), it is not trapped by the SAX Driver and passed to an
> ErrorHandler function.

Yes -- those would be alterations!  By throwing the exception, the
application level code already indicated how it wants to handle the
particular exceptional case.  It'd be different if the SAX spec said
it expects parsers to change normal exception processing.


> > > 2)  A handler method, let's assume EntityResolver::resolveEntity()
> > > encounters an unrecoverable problem.  ... It decides
> > > to wrap this in a SAXException and throw it.  What should happen next?
> >
> > Again, letting the IOException through would be my default expectation,
> > rather than catching it and doing anything.  But that's the application's
> > choice. (Not a parser issue at all.)
> 
> How can it be the application's choice.  

By applying that rule of thumb ... :)


> > (Your terminology is a bit strange -- "trap" and "return" here, and more
> > such elsewhere.  That's not Java terminology or C++ terminology, I'm curious
> > whatlanguage you're assuming.)
> 
> I was trying (dismally) to be language neutral ;-)

Thought that might be the case ... I've found consistency is less likely
to introduce confusion!


> > > 3)  If you answered (b) to either of the above, then what do you think
> > > should be done when ErrorHandler::warning() throws an Exception.  (a)
> > > return
> > > it to parse() or (b) wrap the exception in a SAXParseException and call
> > > ErrorHandler::fatalError().
> >
> > Presumably you mean it throws a RuntimeException or an Error?
> > In both cases, I'd apply the rule of thumb I repeated above.
> 
> No, the signature of ErrorHandler::warning() only allows for a SAXException
> to be thrown.

Well, if you're talking Java then RuntimeException may always be thrown,
likewise for Error.  If you weren't talking about one of those two cases
(and even if you were :) I think that rule of thumb applies:  the app level
code already decided how to handle the exception, no parser should be
trying to second-guess that decision.


> > > 4)  Finally, what about when ErrorHandler::fatalError() rethrows the
> > > SAXParseException, as is the case with DefaultHandler?  This must
> > > obviously be returned to parse() otherwise we'd be in a real pickle.
> >
> > You seem to be using the word "return" to mean the same thing as "throw",
> > which I find really confusing
> 
> I think perhaps you are being pedantic or do you really find this confusing?
> It should not be confusing when you read it in context.  The return type
> from parse() and the ErrorHandler methods is void, so in this context I am
> obviously talking about the exception being propogated back to the caller.


Given your mix of terminology, I was not clear what you were talking
about ... you were using C++ syntax and I don't know of a standard C++
binding for SAX, so who knows what you really meant.  As I said, you
"seem"ed to be meaning that, but I've learned it's dangerous to make
such assumptions when the terminology is clearly nonstandard.


> So, would I be right in thinking that a SAX Driver is never likely to pass a
> SAXParseException to an ErrorHandler method that contains an imbedded
> Exception?  If I'm not, in what circumstances do you think this would occur?

I think it's not likely, though it's possible.  I think a typical case of getting
a SAXParseException with an embedded exception would be when some
application level integrity check turned up an app level data error, and then
delegated the handling of that to an ErrorHandler.  I can imagine that some
parser might use that technique internally, but won't speculate on particular
scenarios ... you might look inside some parsers to see if  they do that.

- Dave