OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More on SAX Exceptions



From: "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.

> > 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.  We are talking about the behaviour
of a SAX Driver.  If a handler method (application code) throws an
exception, then the SAX Driver has a choice of (a) propogating it back to
the caller of parse() or (b) passing it to an ErrorHandler.  I think we
agree, however, that (a) is the natural choice.

> (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
what
> language you're assuming.)

I was trying (dismally) to be language neutral ;-)

> > 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.

> > 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.

> > So, this brings me to my final question: should a SAX Driver ever call
the
> > ErrorHandler with a real (i.e. unexpected) exception, or will these
always
> > be returned to the caller of parse().
>
> You're really confusing me.  Exceptions aren't expected, though they may
> be _permitted_ by exception signatures.

The point I was trying to clarify is whether or not the parse() method
should include a try/catch block and pass any caught Exception (wrapped in a
SAXPArseException) to ErrorHandler::fatalError().  I think that it is now
reasonably clear that this would not be an appropriate course of action.

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?

Regards
~Rob