For clarification only (we're not suggesting adding these NOW, but
instead preserving the option):
People constantly write methods like
public String nonNull(String s) { return s != null ? s : "" }
and other versions (including the more general version that takes a
default, and versions for arrays) because they are getting values from
possibly null-dispensing sources (such as maps or other key-value
stores). They find locutions like
(s != null && s.length() > 0)
to be excessively verbose in these cases. So they write utility methods
that translate null to some benign default (empty string, empty array),
and proceed on their way. People do this all the time; what they want
is for the null check to recede into the background so the program logic
is more apparent.
People hate the fact that if the array/collection is null, foreach
throws NPE; they'd mostly rather not have to deal explicitly with the
null case. Providing a something that reads more smoothly (like
checkNonNull(x)) will make them happier.
On 1/13/2011 6:57 PM, Ulf Zibis wrote:
Am 13.01.2011 23:38, schrieb Brian Goetz:
People use these to simplify cases like
if (foo != null)
for (Foo f : foo) { ... }
to
for (Foo f : nonNull(foo)) { ... }
To be honest, I don't understand the real value of nonNull().
If the argument is null, NPE would be thrown anyway.
Do I miss something?
-Ulf
