RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get() (original) (raw)

forax at univ-mlv.fr forax at univ-mlv.fr
Sun Dec 10 11:47:52 UTC 2017


----- Mail original -----

De: "Stuart Marks" <stuart.marks at oracle.com> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <Alan.Bateman at oracle.com> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> Envoyé: Samedi 9 Décembre 2017 00:48:08 Objet: Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method.

This looks good. The naming is consistent and I think better than the "getWhenPresent" proposed in the original thread. i agree with Alan. Having a name that starts with "get" as the great advantage as to be visible in the IDE completion box just after the method get() so it will help people to transition from get() to getWhenPresent() I'm not sure whether you're agreeing or disagreeing. :-)

oops, read the Alan's reply too fast.

The current proposal is for orElseThrow(). Having a method that starts with "get" (such as "getWhenPresent" or "getOrThrow") is indeed helpful when doing auto-completion, but it sort-of starts to create a new family of get- methods that overlap with the existing orElse- methods in an odd way. I think the no-arg orElseThrow() fits better with the existing three orElse- methods. This leaves get() as the outlier, which is ok if we maybe eventually deprecate it.

ok, make sense.

BTW, i do not see the point to not deprecate get() at the same time. Much of the resistance to the earlier proposal was about deprecation of get(), so I wanted to set that aside in order to proceed with introduction of this alternative.

ok

s'marks

Rémi



More information about the core-libs-dev mailing list