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

Re: SAX2: Should SAXException extend IOException?

  • From: David Brownell <david-b@p...>
  • To: "Clark C. Evans" <clark.evans@m...>
  • Date: Mon, 03 Jan 2000 11:00:43 -0800

einval details
"Clark C. Evans" wrote:
> On Mon, 3 Jan 2000, David Brownell wrote:
> > "Clark C. Evans" wrote:
> > > I guess I'm trying to say that a data format
> > > exception in one context could easily be seen
> > > as an I/O exception in another context.
> >
> > Actually, everything boils down to an EINVAL at
> > some level ... everything else is just varying
> > layers of sugar to explain what was INVAL !  ;-)
> 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).

> 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.

Of course, there are people who write software that's
not robust.  Even managers who insist on it, and make
careers out of fixing the ensuing fires.

>	  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.

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.

> 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.

- Dave

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.