Re: SAX2: Should SAXException extend IOException?
On Mon, 3 Jan 2000, David Brownell wrote: > > Yes. And the detail of such sugar should depend > > upon the task being performed. > > The interface spec captures such details. So for > example "it's not there" (EINVAL) is distinct from > "what's there is corrupt" (EINVAL) is distinct from > "what's there has validity errors" (EINVAL) is also > different from "unsupported encoding" (EINVAL). Of course it would be nice to have a more explicit list of specific exceptions... However, the question was if these exceptions (be it one or many explicit ones) should extend IOException, or should be part of a seperate sub-tree, or should be spread out over several root trees (both IOException and SaxException). > > Rather, a SAX parser is a processing component which takes > > an XML input source and generates an event stream as output. > > It's internal workings are encapsulated -- it does not expose > > highly granular control of its process. > > No exception exposes "control"; it's a fault report, > the processor can't continue, and it's saying exactly > why it couldn't continue. The sugar over "EINVAL" is > critical to enabling robust fault recovery. I don't think we are in disagreement here -- "it" was referring to the parser as a whole, not just the relevant exceptions. As you carefully point out, without relevant exceptions over the possible fault space, you can't make specific corrections, thus control is reduced. > > Thus, possible automated recover schemes are > > (understandably) rather limited. > > Which is why I can't understand the motivation to make > distinguishing the really basic cases be any more error > prone than it already is. Any win is at best minor (not > that I agree there is one), and there are visible costs. What would be helpful (to move the discussion along) is a list of possible use cases for fault recovery. You have a nice starter list above. How about: IOException SaxException SaxInvalidEncodingException SaxInputSourceNotFoundException SaxNotWellFormedException SaxUnknownEntityException SaxMisMatchedElementException ... SaxNotValidException > Bugs in fault handling code are by far the hardest to find > and fix. Strongly typed exceptions are one of the few tools > that have come along to address that in the past decade. Yes, they can be very useful. Especially the C++/Java style exceptions that are not easily ignored (unlike C return values) > > Therefore, it seems perfectly acceptable for the error to be > > generic. Further, if you consider the SAX parser's primary > > task, that of converting an input source to an output stream, > > of the generic errors, IOException seems the best fit. > > You deleted (and then ignored) the points I raised about > why "generic" _reports_ of non-generic errors are bad, so > I'll just say I remain unconvinced. Very sorry. I don't think I was trying to argue against specific exceptions. .. I was attempting to express that, as a core function, the SAX parser is a input/output adapter, converting an XML source as input into a stream of events as output. Therefore, it makes perfect sense for the base exception to be an IOException. Having specific exceptions are a very welcome bonus. Clark 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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