[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SAX Exception Handling
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|