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@e...> > 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format