[jdom-interest] getChildTextNormalize()

[smarks at digisolutions.com]

Bleck, returning "" is worse then returning null.

However, I strongly agree that returning null is problematic as it
does just what you say: rely on the good intentions of coders. An api
should make it hard to screw up even if you are lazy rather than
easier. 

I strongly suspect returning nulls instead of throwing an
appropriate expection extends from a coding tradtion where exceptions
weren't available. In languages where they are available they can (and
should be) be used to consistently indicate error conditions. Having
mix of nulls, maybe some empty strings and some exceptions makes it
harder to write robust code. 


"Kyle F. Downey" <kdowney at amberarcher.com> writes:

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