[jdom-interest] [Vote] NoSuchChildException

[Harry Evans]

-1 on returning null.

I have to agree wholeheartedly with Elliote.

In the case of well formed, but not validated xml, you have to check for
null or catch the exception at every level.

Null is very undescriptive.  While in the particular case being argued, the
only possible values are the element or some report that it does not exist,
this seems to be a pattern that does not carry through to accessors where
there are multiple paths to failure.  In that case, an exception is the only
way to accurately report what went wrong.  Null just can't handle that.

Simply returning null seems to work against the entire idea of exceptions.
While some may argue that is a good thing, I believe the overall exception
mechanism in Java allows an API to demand a certain rigour from the
programmer.  Null has no explicit semantic meaning, whereas exceptions, if
used properly, carry very explicit meaning.  In the case of xml that has
already been validated, no exception will be thrown, and therefore a global
try/catch block is the only overhead to this.

This seems to be early optimization.  If the performance hit is that large,
maybe some form of environment variable for jdom can switch the code to
return null for performance reasons, and highly tuned code can take
advantage of this, and avoid try/catch blocks around the relevant elements,
doing only a global try/catch to satisfy the compiler.

Returning null just seems to hearken back to the days of bad c code and
out-of-band exception handling.

-----Original Message-----
From: Wesley Biggs [mailto:wbiggs at elite.com]
Sent: Wednesday, July 12, 2000 2:52 PM
To: 'Elliotte Rusty Harold'; Brett McLaughlin; jdom-interest at jdom.org
Subject: RE: [jdom-interest] [Vote] NoSuchChildException


<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
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com