OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: SAX/Java: Exceptions, Again

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <ak117@freenet.carleton.ca>
  • To: James Clark <jjc@jclark.com>
  • Date: Fri, 9 Jan 1998 06:36:21 -0500

James Clark writes:

 > The trouble with that approach is that that XmlProcessor.run will have
 > to be declared as throwing Exception, which is horrible and will make
 > things ugly when application writers call run.  I want XmlProcessor.run
 > to be declared as throwing java.io.IOException (there's no way it can be
 > more restrictive that this).

Thank you again for the comments, James, and thank you for raising the
issue of exception handling in SAX in the first place.

I agree that at least java.io.IOException has to be passed through,
but I think that there are some other ones, not derived from
java.io.IOException, that will be nearly as common.  For example, an
application writer could reasonably want to catch exceptions derived
from any of the following at the top level rather than in the
callbacks:

  java.awt.AWTException
  java.beans.IntrospectionException
  java.sql.SQLException

The last will be especially common, since I expect that SAX and the
JDBC will become very intimate friends.

>From a pragmatic perspective, the application writer will usually know
what exceptions (if any) her callbacks actually throw, and I am
allowing a parser (or at least, its SAX front end) to throw only
java.io.IOException, so the try-catch stuff around the parser
invocation should be fairly manageable -- this example, the user knows
that the callbacks throw MyException1 and MyException2 (the parser may
throw IOException as well):

  try {
    parser.parse(null, docUrl);
  } catch (MyException1 e) {
    /* do something */
  } catch (MyException2 e) {
    /* do something else */
  } catch (java.io.IOException e) {
    /* general */
  } catch (java.lang.Exception e) {
    // should never happen
    throw new Error("Unexpected exception! " + e.getMessage());
  }

Finally, I don't want to rule out exceptions from important new Java
libraries over the next few years.


All the best,


David

-- 
David Megginson                 ak117@freenet.carleton.ca
Microstar Software Ltd.         dmeggins@microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe 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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS