Re: SAX/Java: Exceptions, Again
David Megginson wrote [09:20 PM 1/8/98 -0500]: >I think that I've just answered my own question about Exception >handling in the Java implementation of SAX. There is no reason that >the SAX frontend for each parser cannot pack exceptions from the >callbacks into a container and unpack them for the top-level >transparently -- that way, the parser can still have tight >compile-time error checking, but application writers won't have to >jump through hoops to throw exceptions to the top level. [clip] >I still need to define what a SAX parser is allowed to catch and what >it may pass through. Here's a rough sketch: > > >1) A parser must catch all of its own, internal exceptions (i.e. no > SAX parser should throw an exception that others do not -- this can > be managed in the SAX frontend if necessary). > >2) A parser may catch any exceptions derived from > java.io.IOException (that includes the networking exceptions), but > only if it is capable of resolving or working around the problem > corresponding to the exception; otherwise, it must throw it on > through to the top-level user code. > >3) A parser must pass all other exceptions up to the user code. I like this a lot. One question: If the parser is unable to open a file (let's say) I'm assuming that this will cause a java.io.IOException to be thrown and in a fully Java system, the parser might well ignore this and allow the application to catch it. This means that there's no need to have any kind of return code coming out of the Parse() function in the parser interface. In thinking about this for other languages, for languages that support exceptions, we're mandating that the SAX implementations in those languages use exceptions also (since there's nowhere for the return code and the return codes are no specified as part of SAX). And in languages that don't support exceptions, I'm at a loss to say what we'd do. I'm have a funny feeling I'm missing something here, so please help me out if you see what I don't. Assuming that my reasoning is right, I'd propose that we agree on return-codes for the most common situations (yeah, I know that may be hard to nail down). David ================================ David Ornstein Pragmatica, Inc. http://www.pragmaticainc.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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