[jdom-interest] getChildTextNormalize()

[Kent C. Johnson]

Kyle,

Great points, and I completely agree!  I agree a NoSuchElementException and 
NoSuchAttributeException would be the right way to do it, and I also agree 
there should be hasChild() methods.  This is how I have always done things 
in my own code, and not real sure why I didn't think of it sooner in this 
case. :) Since I am less knowledgable about the JDOM source base than the 
rest of you, can anyone think why this isn't the right way to go, or why it 
would conflict with something else?  I would think these added exceptions 
could be useful in other cases too.

I am now near positve that my vote goes towards the below implementation.

Kent


>From: "Kyle F. Downey" <kdowney at amberarcher.com>
>To: "Kent C. Johnson" <kentyman23 at hotmail.com>
>CC: <jdom-interest at jdom.org>, <brett at newinstance.com>
>Subject: Re: [jdom-interest] getChildTextNormalize()
>Date: Wed, 3 Oct 2001 18:58:20 +0000 (GMT)
>
> >
> >     try {
> >         blahText = getChild("blah").getTextNormalize();
> >     } catch (NullPointerException npe) {
> >         blahText = "";
> >     }
> >
>
>I prefer this, with a slight modification.
>
>I designed an API that has similar structure (a hierarchical registry
>instead of XML nodes, but otherwise similar: tree of nodes & attributes).
>Generally, I prefer creating a meaningful runtime exception for this sort
>of thing, which is what Akita does. This has two advantages:
>
>1) there's no need to constantly check for a null return, so there's no
>need for those extended convenience methods
>2) if the child being missing is an error, then this error gets
>propagated up the call chain transparently. The same can apply for
>attributes, by the way. So why not a NoSuchElementException and
>NoSuchAttributeException?
>
>Of course, if your assumption is that a child being missing is normal,
>then those arguments do not make sense. But IMHO, if a client object
>really doubts that a child will be there, it should have a way to check
>first, rather than bulling ahead and requesting it & getting a bad value:
>
>if (node.hasChild(ns, "foo")) {
>    bar = node.getChild(ns, "foo").getText();
>}
>
>At least to me, this makes more sense than using an invalid and
>unusable return value to signal that it's not there. NullPointerExceptions
>are a generally useless way of informing a programmer that he or she
>goofed and should have performed some kind of check beforehand--they're
>so common that the root cause is easily obscured. At least a semantic
>error tells you exactly what you did wrong.
>
>--kd
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp