[jdom-interest] getChildTextNormalize()

[Dennis Sosnoski]

I think most people would agree that null should not be returned for an error
condition. The real question is what's an error condition.

If you interpret an access method to mean "give me this value, and I know it's there",
then "not found" is an error condition and *should* throw an exception. In this case
anyone wanting to retrieve an optional value needs to first check that the value is
actually present.

If you interpret an access method as meaning "give me this value, if it's there", the
null return for a "not found" case makes perfect sense.

Both these choices are reasonable. As for "returning null is problematic as it...", the
distinction seems to be between the method throwing an exception when used to access a
non-existant value vs the application code throwing an exception whne attempting to use
a returned null value. The first is a little clearer to the developer, but not by a
lot.

  - Dennis

smarks at digisolutions.com wrote:

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