[jdom-interest] NoSuch*Exceptions in JDOM

[Petri Wessman]

On Mon, 10 Jul 2000 13:24:43 -0400, Elliotte Rusty Harold <elharo at metalab.unc.edu> said:

Elliotte> This isn't a good test. Most of the time an exception won't
Elliotte> be thrown!  What these tests show is that at worst the
Elliotte> exceptional case takes six times as long as the
Elliotte> non-exceptional case (and normally closer to twice as
Elliotte> long). However if even as many as one in ten calls to
Elliotte> getChild() throw an exception, then even in the worst case
Elliotte> you're still only take about 150% as long as returning
Elliotte> null.

Since 1 in 10 throwing an exception is pretty low in the real world
("real world" XML probably has optional attributes and/or elements
more often than that), your saying that "only about 150% as long" is
pretty scary. If you have a server application that is processing XML
at a high rate, that amounts to a lot of overhead.


Elliotte> (More like 110% if we take the more likely twice as slow
Elliotte> figures). However, even this is deceptive because your tests
Elliotte> didn't do anything when null was returned. A typical
Elliotte> implementation would not only test for null but provide
Elliotte> additional to handle the null case. I just don't see these
Elliotte> numbers being bad enough to make a decision on. Premature
Elliotte> optimization is the root of all evil.

Agreed that benchmarking is difficult, and that "real world" figures
are a bit hard to come by.

To get something realistic, I modified a servlet system I have to use
both the stock JDOM and a hacked JDOM. The system parses an XML
directory into internal form, and does stuff with that. Since the XML
involved has very few optional attributes, it's quite opposite to a
"worst case scenario".

A quick test run revealed that the system used 47 seconds to do its
"scan XML and form directory thingies from it" -routine, while the
same run with a hacked JDOM ate up 39 seconds.

That's a real world case. Now, you might say that 8 extra seconds
isn't that but, but consider:

- this was simple XML that had very few optional attributes, less than
  I normally use.

- this talk about speed is just one facet. The other, and arguably
  more important, point is that it is bad Java coding style to throw
  exceptions in cases like this. So it's both slower, in bad style,
  and does not necessarily make the code simpler (often the opposite,
  see Patrick's previous examples).


Elliotte> I'm still torn, but I think my vote is coming down on the
Elliotte> side of throwing exceptions.  However, I'm completely aghast
Elliotte> at the thought of getChild() and mustGetChild(). Pick one
Elliotte> behavior or the other but not both. Part of the point of
Elliotte> JDOM is to avoid API bloat so it can be simple to learn and
Elliotte> obvious to use.  If you really don't want to throw
Elliotte> exceptions there are already methods in the API that will
Elliotte> return a list containing only children that actually exist.

Well, it should be plain that I disagree completely on this. If JDOM
claims to aim for "making 80% of common tasks easy", but then forces
the programmer to resort to workarounds and hacks in order to perform
*basic* functions, then something does not add up.

Now I obviously can't force you guys to change your design, but I
*really* don't see your point about it being totally impossible to do
(what is to me) the obvious thing, i.e. add a few more access
methods. Especially since it seems a majority of the JDOM users would
really like to see those methods. Avoiding code bloat is
good. Avoiding it in order to promote bad Java design is not.

<off my soapbox now>

//Petri