SAX: Exception Handling

[David Megginson]

James Clark writes:

 > With my application writer's hat on (I just converted XMLTest to the new
 > SAX), the current solution is a significant step backwards.  The typical
 > simple SAX program that processes an XML document and produces some sort
 > of output is going to have to make calls in its DocumentHandler
 > implementation that throw IOExceptions, and each of these methods now
 > have to do:
 > 
 > try {
 >   ...
 > }
 > catch (IOException e) {
 >   throw new SAXException(e);
 > }
 >
 > The original goal of SAX was to be simple and easy to use for
 > application writers.  I don't think requiring this sort of mumbo jumbo
 > even for trivial programs is consistent with this goal.

I stood by the same position for nearly five months, in the face of
very loud opposition from people whose opinions I have great reason to
respect (as I have yours).

However, upon reflection (or perhaps simply mental exhaustion), I
realised that throwing java.lang.Exception was a false economy.  When
I write

 public void endElement (String name)
   throws java.lang.Exception
 {
   [..]
 }

The Java compiler will not help me discover which constructors or
methods invoked in the body can throw exceptions that I have not yet
considered.  With

 public void endElement (String name)
   throws org.xml.sax.SAXException
 {
   [..]
 }

The Java compiler will raise an error the first time I compile.  I
will discover that java.sql.Connection.createStatement (for example)
can throw a SQLException, and I will take steps either to deal with
the exception here in the handler (perhaps by reformulating the query)
or for packing it up to send it to the top level.  Of course, I can
always avoid doing so by wrapping the entire contents of each handler
in a try...catch statement

  public void endElement (String name)
    throws org.xml.sax.SAXException
  {
    try {
      [..]
    } catch (SAXException e) {
      throw e;
    } catch (Exception e) {
      throw new SAXException(e);
    }
  }

By doing so, however, I have consciously pulled the pin out of the
grenade myself, rather than having the grenade handed to me with the
pin already missing.

 > I don't see an ideal solution, but I can think of several possibilities
 > in addition to the old solution and the current solution, any of which I
 > think would be an improvement over the current solution:
 > 
 > 1.  The handler methods are declared to throw both SAXException and
 > IOException (as I proposed for parse).  My guess is that throwing
 > IOException is going to be very common, and will avoid the need for the
 > user to wrap exceptions themselves in a large proportion of simple
 > programs.  I can't see any disadvantages over the current proposal.

Your guess supposes that one class of XML application dominates.
Database applications (and they may come to dominate XML) will more
typically need to throw java.sql.SQLException, while GUI applications
will often need to throw java.awt.AWTException.

 > 2.  A variation on this would be to make SAXException extend IOException
 > and then declare both the handler methods and parse as throwing
 > IOException.

Again, this variation benefits only one group of users.  If
SQLException were a subclass of IOException (for example), then the
choice might be clearer.


All the best,


David

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

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