Nulls

[Doug Lea]

Just for the record, I'm still sure that (3) is a mistake. Oh well.

-Doug


On 09/26/12 16:00, Brian Goetz wrote:
> Trying again to categorize the choices and identify pros/cons...
>
> Seems like there are four buckets here:
>
> 1.  Ban nulls.  This means that feeding nulls into a Stream MUST produce an NPE.
>
> 2.  Ignore nulls.
>
> 3.  Tolerate nulls.  Streams API takes no position on nulls, but may well pass
> elements to less tolerant destinations (e.g., user-provided lambdas,
> user-provided collections, Optional constructor.)  Nulls may cause NPEs in these
> cases.
>
> 4.  Embrace nulls.  Ensure that every operation can deal with nulls in a
> well-defined manner.  (This entails, for example, either dropping the
> Optional-bearing methods or making present Optional deal with null.)
>
>
> I think its safe to say that for each of these, there is some subset of us who
> finds it undesirable.
>
> Doug proposed (2) and (4).  I proposed (3).  Nearly everyone has some sympathy
> for (1) but no one really wants to be that intolerant.
>
>
> Attempted summary of pros/cons:
>
> 1 PRO: Predictable, simple
> 1 CON: Might be overly harsh, interferes with when user might actually want to
> see nulls and can deal accordingly
>
> 2 PRO: Simple
> 2 CON: size() lies, interferes with optimizations, interferes with when user
> might actually want to see nulls and can deal accordingly
>
> 3 PRO: Minimizes distortion on API, implementation in the null-free case
> 3 CON: more complex reasoning about what might happen, op behavior may change
> subtly over time as implementation changes
>
> 4 PRO: Predictable
> 4 CON: sacrifices functionality/safety for sake of a corner case
>
>