[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2: Should SAXException extend IOException?

  • From: "Clark C. Evans" <clark.evans@m...>
  • To: David Brownell <david-b@p...>
  • Date: Mon, 3 Jan 2000 15:07:34 -0500 (EST)

saxexception recovery
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: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...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.