SAX: Exception Handling

[James Clark]

David Megginson wrote:
> 
> 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.

Right, so don't do that.  Declaring an *interface* as throws
java.lang.Exception does not constrain an *implementation* of that
interface to be declared as throws java.lang.Exception.  It can be
declared to throw the appropriate subclass of java.lang.Exception.

If you declare the interface

public void endElement(String name) throws java.lang.Exception;

then I can declare my implementation as

public void endElement(String name) throws java.lang.IOException {

}

or

public void endElement(String name) throws java.awt.AWTException {
}

or whatever is in fact appropriate to my implementation. In other words,
it is only be declaring the interface as java.lang.Exception, that I can
correctly declare the exceptions that by implementation throws and
thereby take advantage of Java's exception checking.

I just don't follow your argument at all.

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

I am not saying it will dominate but I am saying it will be a
significant class, and the other classes wouldn't be hurt by making it
easier for this class. I don't see much merit in the argument that
because we can't make things simpler for *all* applications we therefore
shouldn't make things simpler for *some*.

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)