Loose ends: Optional

Brian Goetz brian.goetz at oracle.com
Mon Jun 10 12:14:07 PDT 2013


> For flatMap, the rationale for "throw on null return" here is that:
> Optional-returning methods should never return null (they should be
> total functions, they can always return either a present or empty
> optional), so a null return should be considered a programming error
> (like trying to unbox the "null" Integer.)
>
> For map, it is different; it is entirely reasonable to imagine that the
> mapper is a partial function, so, just like with computeIfAbsent, we
> should interpret a null return as "no result".
>

Looking at the Fugue implementation, it differs slightly.  Their map() 
treats null-return as empty, and their flatMap simply returns null if 
the mapper returns null.  I am fine with being consistent with Fugue 
here; I think the lambda passed to flatMap should never return null, but 
we don't have to go out of our way to check it if we don't want.

I've got a query into the Fugue guys to see if they're happy with that 
after having used it for a while.


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