Nulls

[Tim Peierls]

On Wed, Sep 26, 2012 at 9:18 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> If the base framework kicks the nullness problem to its users,
> then every user must deal with it. But many of the "users" of java.util
> are not applications programs, but other utilities and frameworks that
> do not know whether the issues apply or not.
>
>
>     ....filter(o -> o != null).findAny();
>>
>>
> No. If this is part of a utility as opposed to application program,
> then it doesn't know if nulls are allowed or not, so has to be
> correct in either case; or else advertise its policy as an
> unchecked precondition.


If such a utility says "Do not pass me nulls or I will do random things",
it's up to the author of that utility to decide what random things to do.
That could mean checking a collection for nulls when it's passed to the
utility or ignoring nulls with filter(o -> o != null) at the last second.
Or it could mean not checking at all. But at least the author of the
utility has that choice.



> Many people will not do either of these.
>

Writers of utilities and frameworks are a small subset of the total user
base. I don't think it's unreasonable to ask them to make a choice between
advertising a null-averse policy (with whatever level of checking they feel
is appropriate) and a null-tolerant policy that kicks the problem on to
their users.



> This is the where most of the mistakes will appear.
>

As Joe points out, we're talking about mistakes in new code mixed with
legacy (null-embracing) code. It's probably true that a lot of those
mistakes will be due either to a failure to advertise (or to observe)
null-averseness or to difficulties defining or following a null-tolerant
policy. I bet the vast majority of these will result in runtime exceptions
that are easily traced back to the source of the mistake. Is failing a
little faster worth ruling out some valid usages and imposing a (tiny)
performance cost? My experience with the Guava analogues of these
constructs tells me it isn't.



> So in the likely event that you choose these rules anyway,
> it would be nice to at least alert the bug-detector folks
> to look for such constructions.


Yes. For filter(o -> o != null) or for the longer try ... catch (NPE)
construction? (Maybe both?)

--tim