[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: ModSAX (SAX 1.1) Proposal

• From: Tyler Baker <tyler@i...>
• To: David Megginson <david@m...>
• Date: Wed, 17 Feb 1999 09:57:29 -0500

David Megginson wrote:

> Jarle Stabell writes:
>
>  > Is it obvious that one should throw exceptions on not supported?  I
>  > believe it in many cases would be more comfortable if it returned a
>  > boolean supported or not instead of throwing an exception, as many
>  > clients probably want/need to check whether a particular feature is
>  > supported or not (and trade off behaviour accordingly)
>
> As I just mentioned in a reply to Don, exceptions provide for cleaner
> code and they help avoid bugs by enabling more compile-time checking.
> It's easy to write
>
>   parser.setFeature("org.xml.sax.features.namespaces", true);
>
> and forget to check the return value, but it's harder to forget to
> catch an exception.

What David is proposing I think makes sense for most uses of SAX.  If you need to do some sort
of dynamic feature querying with the parser, you can write code like this:

boolean namespacesAllowed = false
try {
  parser.setFeature("org.xml.sax.features.namespaces", true);
  namespacesAllowed = true;
} catch (SAXNotSupportedException e) {}

boolean validationAllowed = false
try {
  parser.setFeature("org.xml.sax.features.validation", true);
  validationAllowed = true;
} catch (SAXNotSupportedException e) {}

If an exception is thrown in either of these cases, the boolean flag is not changed to true.
Likewise you could do something a little more elaborate like:

int featureFlags = Features.NONE;
try {
  parser.setFeature("org.xml.sax.features.namespaces", true);
  featureFlags |= Features.NAMESPACES;
} catch (SAXNotSupportedException e) {}

try {
  parser.setFeature("org.xml.sax.features.validation", true);
  featureFlags |= Features.VALIDATION;
} catch (SAXNotSupportedException e) {}

I have had a lot of experience in the past where I thought that using return values to
indicate error flags was a good idea for this sort of thing, but the truth is exceptions are
much nicer for the reasons David stated as well as the fact that at least in the case of
checked exceptions, it makes writing your code and API's more straightforward and easier to
understand.

Tyler


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

• References:
  • RE: ModSAX (SAX 1.1) Proposal
    • From: Jarle Stabell <jarle.stabell@d...>
  • RE: ModSAX (SAX 1.1) Proposal
    • From: David Megginson <david@m...>

• Prev by Date: Re: XML conferences in the UK
• Next by Date: RE: XML conferences in the UK
• Previous by thread: RE: ModSAX (SAX 1.1) Proposal
• Next by thread: Re: ModSAX (SAX 1.1) Proposal
• Index(es):
  • Date
  • Thread