SAX RFD: ModSAX Predefined Features

[Glenn Vanderburg]

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