Updated State of the Collections

[Brian Goetz]

Exactly right.  The benefit of the current approach is that allows users 
to simulate any of the other approaches (filter nulls, throw on nulls) 
relatively easily.

The disadvantage of the current approach is it requires users to reason 
about nulls in error-prone ways, and people are likely to be caught off 
guard by not realizing that their sources might contain nulls.


On 11/18/2012 7:38 AM, Arne Siegel wrote:
> Another possible way to express the not-null-ness requirement in the current API:
>
> .map(Objects::requireNonNull)
>
>
> Or, when desiring control of the NPE message:
>
> .map(e -> Objects.requireNonNull(e, "null disallowed in stream"))
>
>
> Best regards
> Arne Siegel
>
>
>
> On 16 Nov 2012 at 17:38, Sergey Kuksenko wrote:
>
>> I have to note that suggested null handle example is not a filter. It is
>> an assert and the following explicit methods would be useful:
>>
>> Stream<T> assert(Predicate<? super T> predicate);
>>
>> and one of (or both):
>>
>> Stream<T> assert(Predicate<? super T> predicate, Supplier<Throwable>
>> throwFactory);
>>      or
>> Stream<T> assert(Predicate<? super T> predicate, Supplier<String>
>> messageFactory);
>>
>>
>> Open questions:
>> - name of methods (assert is keyword),
>> - to do connections with "-ea" option or not?
>>
>>
>> On 11/16/2012 02:26 PM, Arne Siegel wrote:
>>> Just one observation: the proposed way to handle the "error" strategy for nulls won't compile,
>>> as it fails to comply the contract for a Predicate:
>>>
>>> filter(e -> { (if e == null) throw new NPE(); }
>>>
>>>
>>> I can think of two compilable alternatives:
>>>
>>> filter(e -> { (if e == null) throw new NPE(); else return true; }
>>>
>>> tee(e -> { (if e == null) throw new NPE(); }
>>>
>>>
>>>
>>> On 15 Nov 2012 at 13:31, Brian Goetz wrote:
>>>
>>>> is here: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Sergey Kuksenko
>>
>
>
>