[jdom-interest] [Vote] NoSuchChildException

[Wesley Biggs]

<Elliotte>
Whichever way the vote goes, 
this method will cause exceptions. The only question is whether these 
will be NoSuchChildExceptions that will be caught in a relevant catch 
block, or uncaught NullPointerExceptions that bring the whole program 
down.
</Elliotte>

That's not quite true.  You're making an assumption that I understand but
disagree with -- that the typical JDOM programmer will write code that is
prone to NullPointerExceptions.

I agree that it's awfully convenient to be able to write
elem.getChild("foo").getChild("bar").getAttribute("baz")
And I agree that if you do that without knowing whether those things exist,
you'll get an exception, and that's bad code.

I would make the use case that before I go using a construct like the
example above, I would have validated the tree against my schema so that I
know it's good.  (And I would make an additional case that the code in a
"pure JDOM" validator is going to have to call the getXXX() methods, and the
speed of validation really counts.)

Using null return values puts more responsibility on the programmer, but
also allows him or her more flexibility.  As a programmer, I want power, and
I'm willing to take the responsibility that comes with that.  If that means
I always check for null before motoring on down a JDOM branch, I can handle
that.  But if I know via schema or other means that my branch is valid, I
don't want to have to catch an exception that cannot occur.

The fact is, you can't force a bad programmer to write good code by paving
the API with good intentions.  Elliotte is absolutely right that many
programmers fundamentally don't understand exceptions -- but forcing them to
use them is not going to change that!

+1 for null.

Wes