Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
|||||||||
