SAX2: Should SAXException extend IOException?
Ray Waldin
rwaldin at pacbell.net
Thu Dec 23 11:05:40 GMT 1999
from David's SAX2 Exceptions proposal:
> 5. Have all callbacks that formerly threw SAXException throw
> IOException instead. This should help to avoid a lot of exception
> tunneling.
I don't see the point in a Handler throwing an IOException to a Parser in most
cases. That is what this item implies, right? What could a DocumentHandler
mean by throwing an IOException during a call to startElement? The I/O has
already occurred before the handler gets involved. The only times I can think
of where it *does* make sense is:
- EntityResolver.resolveEntity(), where the handler is taking part in IO
- ErrorHandler.*(), where a handler is passed an exception and may reflect it
back to the parser
-Ray
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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)
More information about the Xml-dev
mailing list