Exceptions or not (Was: RE: ModSAX (SAX 1.1) Proposal)

[Jarle Stabell]

David Megginson wrote:

> As I just mentioned in a reply to Don, exceptions provide for cleaner
> code

Generally I agree.

> and they help avoid bugs by enabling more compile-time checking.

I haven't used Java much, so personally I don't know whether I find this 
forced declarations of exception throwing a good thing.
(It seems to me quite a lot of people throws in the towel and just writes 
"throws exception")


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

True. But in this case, if the parser-client wants to trade features based 
upon what is supported or not, I guess you really need to inspect (and 
perhaps store the result) for each particular feature, whether it was 
supported or not (or just set it in case it is supported, and don't care if 
it is not).
Then this part of the code becomes somewhat uglier with exceptions.

If the typical case is (f.i.) : "I want Namespaces, X-Link, X-Schema and 
X-Pointer, and if I don't get all of these, I won't use you" (ie a 
conjunctive condition), then exceptions works very well, but if you don't 
want to throw in the towel the moment a single feature is not supported, 
exceptions could give uglier code than without them.

Of course, this mail is only about minor details which doesn't matter much. 
If one needs to do a "lot of" reasoning based upon which features are 
supported, it is trivial to make a wrapper function which transforms the 
exception (or not) into a boolean value.

Cheers,
Jarle Stabell


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)