Lists Home |
Date Index |
- From: "Clark C. Evans" <firstname.lastname@example.org>
- To: David Brownell <email@example.com>
- Date: Mon, 3 Jan 2000 15:07:34 -0500 (EST)
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:
> 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.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)