[jdom-interest] NoSuch*Exceptions in JDOM

[Petri Wessman]

On Mon, 10 Jul 2000 12:02:45 -0500, philip.nelson at omniresources.com said:

>> I see the problem in your test case: you're testing for a child which
>> exists in the XML. In this case the difference between the methods is
>> non-existent (as your test proves).
>> 
>> Declaring that something throws exceptions is not expensive. Actually
>> throwing the exceptions is.

philip> Ah, I see now why this is an issue for you.  I was thinking of
philip> the null test for a situation that occured infrequently.  I
philip> have little doubt that if exceptions are regularly thrown,
philip> they would incur a performance hit.  I never pay much
philip> attention to performance with exceptions because they should
philip> not be frequently thrown.

Yup, and I agree with that. The problem (and this discussion) is about
the fact that the current JDOM *requires* you generate exceptions when
dealing with XML that has optional elements and/or attributes (which
covers probably 80% of all XML :).

philip> In one of my first applications to use JDOM, I didn't want to
philip> throw exceptions for missing attributes AND I wanted to use
philip> the same code for documents that may or may not supply all the
philip> attributes.  I was able to structure the code so that
philip> accessing the "optional" attributes was defered until I really
philip> needed them, and so that I didn't ever have to access them
philip> unless they were there. But that was just one app. In my case
philip> I simply add missing attributes.  How's that for a performace
philip> hit?

Sure you can hack around the current JDOM problem (for example, get a
List of the attributes and scan through them), but it's clumsy,
wastefull and verbose. I would like to not have to resort to hacks in
order to get a normal "base" XML operation done. ;}

...
philip> methods. I DO NOT want to change the current methods.  I think
philip> there are clearly cases where exceptions should be thrown and
philip> java doesn't give use the option of turning off an exception.
philip> This way we get something that everyone can use and Brett's
philip> book is still valid, not a bad thing if this api takes off
philip> like it appears to be taking off.

Yup, I agree. I'm not advocating changing the current "base" access
methods, since they are already in use and in Brett's (very good!)
book. I would merely like to see some alternative access methods for
elements and attributes that would allow processing them without
exceptions. Best of both worlds, and all that.

//Petri