Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: More on SAX Exceptions
 From: "David Brownell" <david-b@p...> > 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 
|
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
|
|||||||||
