Cart
[Home] [By Thread] [By Date] [Recent Entries]
David Megginson wrote: > I think that I've just answered my own question about Exception > handling in the Java implementation of SAX. There is no reason that > the SAX frontend for each parser cannot pack exceptions from the > callbacks into a container and unpack them for the top-level > transparently -- that way, the parser can still have tight > compile-time error checking, but application writers won't have to > jump through hoops to throw exceptions to the top level. The trouble with that approach is that that XmlProcessor.run will have to be declared as throwing Exception, which is horrible and will make things ugly when application writers call run. I want XmlProcessor.run to be declared as throwing java.io.IOException (there's no way it can be more restrictive that this). There's no perfect solution, but I think it would be worth considering restricting callbacks to throwing java.io.IOException. This would allow run can be declared as throwing java.io.IOException. This isn't much of a burden on application callbacks: IOException is fairly broad in Java, and the callbacks are processing input so it isn't unreasonable to restrict the exceptions they throw to IOException. Also this wouldn't require parser writers to catch and repack exceptions thrown by application callbacks. 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...)
|
