SAX Exception Handling

[James Clark]

David Megginson wrote:
> 
> James Clark writes:

>  > It's probably too late for this, but I'm having problems seeing the
>  > logic in the exception handling design.  The design seems to make
>  > things inconvenient for both users and implementors: implementors
>  > have to wrap SAXException in order to pass it up through their
>  > parsers, and in handler methods users have to wrap their exceptions
>  > in SAXException.
> 
> The former problem exists only when SAX support comes through a
> separate driver (as, admittedly, is usually be the case).  A new
> parser, written from scratch, could include SAXException in its throw
> clauses without using a wrapper.
> 
> The latter problem is very annoying, but there seems to be no
> obviously correct solution.  I received a very, very large number of
> objections to my use of java.lang.Exception.  I don't want to
> vacillate any more, and have settled on a SAXException wrapper simply
> as the (slightly) lesser of two evils.

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

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

3.  Another possibility would be keep the handler methods declared as
throwing java.lang.Exception but declare parse as throwing
SAXException.  In other words it would be the responsiblity of the
parser to do something like:

try {
  handler.startDocument();
}
catch (RuntimeException e) {
  throw e;
}
catch (Exception e) {
  throw new SAXException(e);
}

around each call of a SAX handler method.  This makes life slightly
harder for application writers but makes life much easier for users.  I
can see the objection to having parse throw java.lang.Exception, but I
can't see the objection to having the interface handler methods throwing
java.lang.Exception.  Implementations of that interface are free to
declare that they throw only some subclass of java.lang.Exception, and
so no exception type checking is lost.  It does make life a little
harder for the parser writer, but I think they can cope: you could even
declare a convenience class that wrapped around a DocumentHandler and
dealt with the exception wrapping:

class DocumentHandlerWrapper {
  DocumentHandler handler;
  DocumentHandlerWrapper(DocumentHandler handler) {
    this.handler = handler;
  }
  void startDocument() throws SAXException {
    try {
      handler.startDocument();
    }
    catch (RuntimeException e) {
      throw e;
    }
    catch (Exception e) {
      throw new SAXException(e);
    }
  }
  // ...
}

The parser writer could just wrap a DocumentHandlerWrapper around the
users DocumentHandler and get the same convenience they get with the
current solution.

James

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)