xml-dev - Re: SAX2: Should SAXException extend IOException?

["Clark C. Evans" <clark.evans@manhattanproject.com>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)