[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Exception Handling
David Brownell wrote: > James Clark wrote: > > 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. > > But then since application programmers write to interfaces, not > implementations, then application programmers would have all those > nasty problems with getting handed random exceptions. > > A primary intent of exception declarations is to constrain the > kinds of errors that a substystem (e.g. parser) reports, so that > its clients have a clean "contract" and know exactly the kinds of > "expected faults" they have to deal with. You're not distinguishing two quite different uses of interface: 1. There are interfaces like Parser. These are interfaces that are implemented by the SAX implementation and called by clients of the application. For interfaces that are used in this way, I completely agree with the points you make. I did not suggest that methods on parser should be declared as throws Exception: they should be declared as throws SAXException. 2. There are interfaces like DocumentHandler. These are not implemented by the SAX implementation, nor are they called by the client. Instead the reverse is true: these are called by the SAX implementation and implemented by the client. Your arguments don't carry through to interfaces that are used in this way. Declaring methods in these interfaces as throws Exception does not cause a client to have to deal with random errors because they are not called by the client. Nor does it require the parser to deal with random errors > Clauses like "throws Exception" are basically counter to the core > philosophy of exceptions in Java. It's not that simple. The real problem ehere is the lack of parameterized types in Java. If Java had a concept of parameterized types, we could get the typing exactly write, eg (using a C++ like syntax): template<class ET> interface DocumentHandler { void endElement(String name) throws ET; } template<class ET> interface Parser { void setDocumentHandler(DocumentHandler<ET> handler); void parser(InputSource in) throws ET; } class MyDocumentHandler implements DocumentHandler<IOException> { void endElement(String name) throws IOException { } } class Demo { void foo(Parser<IOException> parser) { parser.parse(new MyDocumentHandler()); } } The use of Exception that I'm arguing for is analogous to the use of Object in a class like Vector. Because Java doesn't have parameterized types, you can't express the idea that the type you can get out of the Vector constrains the type you can put in (or vice-versa), so you have to settle for using Object. Similarily with SAX you can't express that the idea that the type of the exception that the Parser can throw contrains the type of the exception that the handler methods can throw, so you have to settle for using Exception. Just as with Vectors, you can easily add a type-safe wrapper: interface IODocumentHandler extends DocumentHandler { void endElement(String name) throws IOException; } class IOParser { Parser parser; public void setDocumentHandler(IODocumentHandler handler) { parser.setDocumentHandler(handler); } public void parser(InputSource in) throws IOException { try { parser.parse(in); } catch (SAXException e) { // The cast can't fail since the DocumentHandler is an // IODocumentHandler that can only throw IOExceptions throw (IOException)e.getException(); } } } With this wrapper I now get a version of SAX specialized for handlers that throw IOExceptions. Using this wrapper I get complete exception type-safety. I can similarily do a wrapper for AWTException or SQLException which will give me exception type-safety for applications using AWT or SQL. Note that these wrappers have minimal run-time cost, because the handler methods are called directly. The more I think about this the more certain I am that having the handler methods declared as throws Exception is the right 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
|