Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8140281

(opt) add no-arg orElseThrow() as preferred alternative to get()

    Details

    • Subcomponent:
    • Resolved In Build:
      b36

      Backports

        Description

        Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet; deprecation is covered by the follow-on issue JDK-8160606.

        The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.

          Issue Links

            Activity

            smarks Stuart Marks created issue -
            smarks Stuart Marks made changes -
            Field Original Value New Value
            Status New [ 10000 ] Open [ 1 ]
            smarks Stuart Marks made changes -
            Parent JDK-8065614 [ 4756830 ]
            Issue Type Enhancement [ 7 ] Sub-task [ 5 ]
            smarks Stuart Marks made changes -
            Summary deprecate Optional.get() and add an equivalent replacement deprecate Optional.get() and replace it with Optional.getWhenPresent()
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics. Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives such as Optional.getOrThrow() are confusing since the other "or-throw" methods take an exception supplier, and this one does not.
            smarks Stuart Marks made changes -
            Labels api-grab-bag api-grab-bag noreg-jck
            smarks Stuart Marks made changes -
            Link This issue relates to JDK-8157055 [ JDK-8157055 ]
            smarks Stuart Marks made changes -
            Link This issue relates to JDK-8160606 [ JDK-8160606 ]
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives such as Optional.getOrThrow() are confusing since the other "or-throw" methods take an exception supplier, and this one does not.
            Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
            smarks Stuart Marks made changes -
            Summary deprecate Optional.get() and replace it with Optional.getWhenPresent() add replacement for Optional.get()
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. It should be deprecated and replaced with a more descriptively named method that has the same semantics.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
            Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
            bchristi Brent Christian made changes -
            Labels api-grab-bag noreg-jck api-grab-bag jep-277 noreg-jck
            smarks Stuart Marks made changes -
            smarks Stuart Marks made changes -
            smarks Stuart Marks made changes -
            Priority P4 [ 4 ] P3 [ 3 ]
            smarks Stuart Marks made changes -
            Fix Version/s tbd_major [ 11972 ]
            smarks Stuart Marks made changes -
            Summary add replacement for Optional.get() (opt) add replacement for Optional.get()
            smarks Stuart Marks made changes -
            Summary (opt) add replacement for Optional.get() (opt) add no-arg orElseThrow() as preferred alternative to get()
            Hide
            smarks Stuart Marks added a comment - - edited
            A previous proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. However, the "when" seemed to connote time, not the notion of definiteness, misleading people into thinking that it did something like blocking until a value was present. Alternatives include getOrThrow() and orElseThrow().

            Previous review thread of proposal that included deprecation of Optional.get():

                http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040484.html
            Show
            smarks Stuart Marks added a comment - - edited A previous proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. However, the "when" seemed to connote time, not the notion of definiteness, misleading people into thinking that it did something like blocking until a value was present. Alternatives include getOrThrow() and orElseThrow(). Previous review thread of proposal that included deprecation of Optional.get():      http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040484.html
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is Optional.getWhenPresent(). This name reinforces the assumption the caller is making, namely that the value is present. Alternatives include getOrThrow(), orElseThrow(), and possibly uncheckedGet(). Something like Optional.getOrThrow() may be confusing since the other "or-throw" methods take an exception supplier while this one does not.
            Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
            Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
            smarks Stuart Marks made changes -
            Description Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet, because it would create too many deprecation warnings. Deprecation should be handled by the follow-on issue JDK-8160606.

            The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
            Optional.get() is an "attractive nuisance" and is too tempting for programmers, leading to frequent errors. People don't expect a getter to throw an exception. A replacement API for Optional.get() with equivalent semantics should be added. The specification for Optional.get() should direct readers to the new API. However, Optional.get() shouldn't be deprecated just yet; deprecation is covered by the follow-on issue JDK-8160606.

            The current proposal for replacement is a no-arg Optional.orElseThrow(). This fits well within the family of or-else methods, and it's closely related to orElseThrow(exSupplier), as if providing a NoSuchElementException supplier as a default.
            smarks Stuart Marks made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Understanding Fix Understood [ 10001 ]
            Hide
            smarks Stuart Marks added a comment -
            Show
            smarks Stuart Marks added a comment - Review thread of updated proposal: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050465.html
            smarks Stuart Marks made changes -
            Fix Version/s 10 [ 16302 ]
            Fix Version/s tbd_major [ 11972 ]
            smarks Stuart Marks made changes -
            Link This issue csr for JDK-8193280 [ JDK-8193280 ]
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk/jdk/rev/7acf5700d542
            User: smarks
            Date: 2017-12-14 03:23:53 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk/jdk/rev/7acf5700d542 User: smarks Date: 2017-12-14 03:23:53 +0000
            hgupdate HG Updates made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolved In Build master [ 18256 ]
            Understanding Fix Understood [ 10001 ]
            Resolution Fixed [ 1 ]
            hgupdate HG Updates made changes -
            Resolved In Build master [ 18256 ] b36 [ 17434 ]
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8193650 [ JDK-8193650 ]
            smarks Stuart Marks made changes -
            Labels api-grab-bag jep-277 noreg-jck api-grab-bag jep-277 noreg-jck release-note=yes
            smarks Stuart Marks made changes -
            Parent JDK-8180205 [ 4928821 ]
            Issue Type Sub-task [ 5 ] Enhancement [ 7 ]

              People

              • Assignee:
                smarks Stuart Marks
                Reporter:
                smarks Stuart Marks
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: