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



In all cases, rule of thumb:  if the handler throws an exception, the parser
should be passing it through unaltered.  Cleanup should be done in "finally"
clauses; that's what they exist to do.  It doesn't matter which of the types
of exception gets thrown (SAXException, IOException, RuntimeException)
or even if it's an Error.  The exception signatures are designed so that when
handlers report exceptions, they don't need to be fixed up anywhere.


From: "Rob Lugt" <roblugt@elcel.com>

> 1)  The SAX Driver encounters some kind of system exception, let's say it
> gets an I/O error attempting to read the document entity.  Should this (a)
> be thrown as a SAXException returned from parse() or (b) should it be
> wrapped in a SAXParseException and handed over to
> ErrorHandler::fatalError()?

Normally I'd expect the SAX parser ("driver"?) to just let the IOException
through.  That's what the parse() signature implies.  Though of course the
parser is permitted to choose (b) ... (a) seems plainly wrong, that's
why the parse() signature includes IOException:  so it's got a natural way
to report the inevitable IOExceptions.


> 2)  A handler method, let's assume EntityResolver::resolveEntity()
> encounters an unrecoverable problem.  It traps an IOException.  It decides
> to wrap this in a SAXException and throw it.  What should happen next?
> Should this exception be (a) returned to the caller of parse() or (b) should
> it be wrapped in a SAXParseException and reported to an ErrorHandler if one
> exists?

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

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


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


> 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 since exceptions are objects that you can do
either of those with.  And I'm not sure what you mean to imply by saying
"rethrow", since the exception object was never thrown in the first place.
It was only created and passed to fatalError().


> 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.  And while they could be returned,
they're most interesting when they're thrown.  Could you maybe rephrase
these last couple questions with consistent terminology?

- Dave