brian.goetz at oracle.com
Sun Sep 23 07:55:21 PDT 2012
> The main downside is that findAny is forced to lie (reporting absent)
> if a null item matches predicate.
I'm not sure I'd describe throwing as "reporting absent", but I see the
point -- we may make a distinction of "its not the stream throwing, its
the optional", but users may not see the difference. But, in any case,
as downsides go (and there has to be one), this one doesn't seem as bad
as most of the alternatives.
If users want a non-null result in cases like this, they can add a
.filter(o -> o != null) and order is restored. (The same way they'd
deal with any null-hostile target and null-friendly stream; explicitly
filter out the nulls.) If we want to make this idiom prettier we can
add Objects::isNull / Objects::isNonNull).
Giving the user the choice of filtering the nulls explicitly or not
seems better than either implicitly filtering or implicitly throwing.
(Yes, Option-bearing findXxx is implicitly throwing, which makes for a
slightly more complex rule.) In the happy case, it doesn't make a
difference, but in the unhappy case, users are in full control.
> Unless you want to reconsider
> whether present Optionals can be null. Which no one seems to want to do.
More information about the lambda-libs-spec-observers