SAX2: Should SAXException extend IOException?

[David Megginson]

Hill, Les writes:

 > David Megginson writes:
 > > In the end, though, this is a relatively minor point.  The important
 > > point, for me, is that SAXException extend IOException -- I 
 > > think that 
 > > it would be convenient to have the callbacks throw IOException rather
 > > than SAXException (otherwise, other IOExceptions will have to 
 > > tunnel), 
 > > but it's not a show-stopper if everyone else thinks it's a bad idea.
 > 
 > I'll agree it is a relatively minor point, but if the only reason is
 > "otherwise, other IOExceptions will have to tunnel" then it is a truly
 > horrible idea which at its extreme boils down to 'Lets just throw Exception
 > so that no exceptions are tunneled'.  Perhaps there is a more cogent
 > argument to made about it?

Well, no, that's just an aside.  There are two main points:

1. Is SAXException logically a kind of I/O exception?

   After a lot of thought (and practical experience writing apps and
   libraries that use SAX), I'm certain that the answer to this
   question is 'yes'.  I know that to many of us on the list, XML is
   the sun, the moon, and the stars, but for the rest of the world
   it's just a fancy format that you can write information to or read
   it from -- in other words, XML is almost never the point, just a
   means.

   From that point of view, reading information from an XML document
   is a kind of I/O, so it makes sense for SAXException to be a kind
   of IOException.


2. Should SAX2 callbacks throw IOException or SAXException?

   This is the trickier one of the two, and it really depends on your
   perspective.  From a pure XML perspective, it would be best to
   have the handlers throw SAXException, because any errors should be
   strictly XML-syntax-related.  

   For someone using XML as an interchange format, however, the goal
   is to get the information that the XML document represents, and the
   niceties of the distinction between XML syntax errors and other
   kinds of I/O errors is not really significant.  If the XML markup
   points to another file, and I cannot read that file, it's just as
   much an I/O problem as if the document itself is malformed: in both
   cases, I've failed to load the information I want, so it's an I/O
   failure.  I'm not as confident of this point, but that's the best
   argument I can put forward for it.

   The tunnelling point can be paraphrased as "if we're dealing with
   I/O anyway, why force IOExceptions to be tunnelled".  As an
   interested historical note, though, the very first prototype SAX
   handlers I posted, about two years ago, did throw Exception.


So, to summarize, I'm pretty sure that a SAXException is a kind of
IOException, but I'm still trying to figure out whether it's best for
SAX callbacks to throw SAXException (as in SAX1) or IOException.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)