SAX/Java: Exceptions, Again

[James Clark]

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