[jdom-interest] [Vote] NoSuchChildException

[Alex Chaffee]

On Wed, Jul 12, 2000 at 03:44:37PM -0700, Harry Evans wrote:
> -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.

But if you're writing an accessor you can declare your own exception
and throw it if need be.  We're asking whether the JDOM library code
should return null; by your own admission, in this method, null is
perfectly descriptive.


> Simply returning null seems to work against the entire idea of exceptions.

As has been argued many times, exceptions carry a lot of baggage
(conceptual/clarity more than performance), and should not be used
when a simple compare will suffice.


> 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.

Null has explicit semantic meaning in this case.  It means "there is
no such object."  There is *no* other possible interpretation.  

(Unless there's a bug in the JDOM library code.  Let's hope that we
are good enough programmers that we won't allow buggy code to ship.)


>  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.

Huh?  If no exception will be thrown, then a global try/catch block is
completely useless, and is exactly the kind of obfuscation we're
trying to avoid.


> 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.

It's more optimizing for clarity than optimizing for performance,
though you do get a noticeable performance improvement under current
JVMs for avoiding exceptions.

(I assume your speculative suggestion wasn't meant to be realistic.
With all due respect, I can think of 4 flaws in it right off the bat.)


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

Saying you should *never* use null because it's *possible* to use it
improperly is like saying you should never use JSP because it's
possible to use it improperly.  Hmm, that sounds familiar...

 - Alex


-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/