Re: SAX RFD: ModSAX Predefined Features
John Cowan wrote: > > > public abstract void setFeature (String featureID, boolean state) > > throws SAXNotSupportedException; > > 2) This method is allowed to throw a SAXNewParserException, which > encapsulates a replacement parser. There are two problems with this. First: let's not use exceptions to report non-error conditions. There are theoretical and practical reasons to restrict the use of Java exceptions to reporting errors. (On a related note, I would like to propose an explicit "boolean featureSupported(String featureID)" query method to make it possible to test for a feature without risking an exception. If anyone would like details of why it's bad to have exceptions as a part of normal control flow, let me know.) Second: if an application needs to implement certain features by pushing filters from the bottom, it can encapsulate the entire process on its own, using a composite, and the process never needs to be exposed through the ModSAX API. (I'm new to this discussion, so forgive me --- but let me know --- if I'm rehashing old debates.) ---glv 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/ and on CD-ROM/ISBN 981-02-3594-1 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