Nulls

Joe Bowbeer joe.bowbeer at gmail.com
Wed Sep 26 06:36:58 PDT 2012


All of the rules have implications for writers of new code that interfaces
with legacy code.

But only writers of new code are affected, right?

On Wed, Sep 26, 2012 at 6:18 AM, Doug Lea wrote:

>
> On 09/25/12 10:48, Brian Goetz wrote:
>
>> null-aware as much as simply null-inappropriate -- i.e., don't use this
>> method
>> if you have nulls in your streams -- which means that the user does has
>> to be
>> null-aware.  Which I think is your point -- the user has to reason about
>> it.
>>
>
> Yes. 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.
>
>
>     boolean present;
>>>    T x;
>>>    try {
>>>         Optional<T> r = ...findAny(...);
>>>         if (present = r.isPresent()) x = r.get();
>>>    } catch(NPE ex) {
>>>        present = true;
>>>        x = null;
>>>    }
>>>
>>> Not very nice.
>>>
>>
>> Or more nice:
>>
>>     ....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. Many people will not do either of these.
> This is the where most of the mistakes will appear.
> 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.
>
>
> -Doug
>
>


More information about the lambda-libs-spec-observers mailing list