[jdom-interest] [Vote] NoSuchChildException

Petri Wessman orava at termiitti.akumiitti.fi
Thu Jul 13 05:50:08 PDT 2000

On Thu, 13 Jul 2000 08:26:52 -0400, Elliotte Rusty Harold <elharo at metalab.unc.edu> said:

>> Putting benchmark references in the form of "claimed benchmarks"
>> implies that the results and/or the claimers or the results are
>> suspect, which I find a bit insulting. There are numerous sources for
>> the fact that throwing exceptions in Java is very expensinve compared
>> to return values. These sources are supported by my quick benchmarks,
>> such as they are. If you knew the design of the typical JVM, it should
>> be obvious to you why exceptions are comparatively slow in Java.

Elliotte> I still stick to this point. I found the benchmarks posted
Elliotte> to be thoroughly misleading and deceptive. They failed to
Elliotte> take into account the fact that far more often than not no
Elliotte> exception would be thrown.  Exception handling in Java VMs
Elliotte> is designed, quite rightly, to be zero cost in the case
Elliotte> where no exception is thrown.

Ok, this probably cuts to the core of the matter. In my view missing
optional elements/attributes are normal and in no way "exceptional",
therefore using exceptions to trap them in bad. You're following the
opposite viewpoint, in which missing optionals are exceptional, and
should (rightly) generate Java exceptions.

Hmmm. As far as I know, optional elements/attributes are part of XML
core, and I for one use them extensively. Practically every DTD that
I've done has a lot of optional data, and my code to handle them needs
to figure out when they are there and when not. So in my code,
exceptions *are* thrown by JDOM a lot. Maybe I'm using XML the wrong
way, and should not use XML optionals, but so far I haven't run into
any material that suggests you should not use them.

Elliotte> Maybe the real point of contention is that I think not
Elliotte> getting something you ask for by name is an exceptional
Elliotte> condition, similar to trying to open a file that turns out
Elliotte> not to exist; whereas some other posters seem to feel that
Elliotte> it's quite natural that something they ask for by name
Elliotte> wouldn't be there. That view just seems strange and alien to
Elliotte> me. As somebody else pointed out, if you really don't expect
Elliotte> that the child will be there when you ask for it, then
Elliotte> what's needed is a method to ask whether it exists.

Yes, that would be fine also (and the above paragraph clarifies your
pov quite well, thanks).

Having the access methods return null would result in the cleanest
code *for me*, but I would also be fine with something like
hasElement(name) and hasAttribute(name). As long as I have some
compact way of detecting missing optionals without triggering


More information about the jdom-interest mailing list