On 28 January 2015 at 17:09, Paul Sandoz <paul.san...@oracle.com> wrote: >> I guess having a method like this makes it easier for people to deal with >> their possibly-null-producing code in a new streams world. Such >> null-producing code already exists. I guess you could say that providing >> this method encourages people to continue producing nulls, but everybody is >> already doing this today, so.... >> > > I had the same view as Remi (mostly still do) with regards to the wrong > signal, but there is stuff out there that returns null and when one finds > oneself on the wrong side of that null it's rather annoying.
Whether a team understands the benefits of avoiding null or not is often orthogonal to whether the APIs a team interacts with avoid null. A method like this is useful at those boundaries and painful when missing. As such, I support the addition. Stephen
