RFR 8164934: Optional.map() javadoc code example is incorrect

[Remi Forax]

Looks good.

At some point we should provide a way to de-activate checked exception in Java !
I vote for 10. I know it's a bold move but
seriously checked exception are fine as feature until you try to compose it with another feature.

This is a perfect example of why checked exceptions are a bad feature. If you take a look to the code, you do not see why it is wrong. From a language that make readability of the code one of its most important goals, I think we should stop pretending that checked exceptions are a feature.

Automatic exception transparency (otherwise it's not backward compatible) works like @SafeVarags, you have to know the precise implementation to guarantee that an exception do not escape (stored in a Future by example), so it's not practical. 

The only benefit of checked exception is documentation, i think it was an important factor in the early days of Java. But now, we are used to document any exceptions checked or not. So we should recognise that checked was an idea of the past (like multiple inheritance) and move on.

regards,
Rémi 


On November 9, 2016 12:52:38 AM GMT+01:00, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>Hi,
>
>Please review an update to the api note of Optional.map() which
>embarrassingly contained erroneous code (labouring under the
>misapprehension that exception transparency is supported!).
>
>I tweaked the example to refer to a Stream<URI> where a URI is
>transformed into a Path.
>
>Paul.
>
>diff -r df7e627c7224
>src/java.base/share/classes/java/util/Optional.java
>--- a/src/java.base/share/classes/java/util/Optional.java	Tue Nov 08
>15:28:44 2016 -0800
>+++ b/src/java.base/share/classes/java/util/Optional.java	Tue Nov 08
>15:37:23 2016 -0800
>@@ -214,20 +214,20 @@
>      * @apiNote
>* This method supports post-processing on {@code Optional} values,
>without
>  * the need to explicitly check for a return status.  For example, the
>-     * following code traverses a stream of file names, selects one
>that has not
>-     * yet been processed, and then opens that file, returning an
>-     * {@code Optional<FileInputStream>}:
>+     * following code traverses a stream of URIs, selects one that has
>not
>+     * yet been processed, and creates a path from that URI, returning
>+     * an {@code Optional<Path>}:
>      *
>      * <pre>{@code
>-     *     Optional<FileInputStream> fis =
>-     *         names.stream().filter(name -> !isProcessedYet(name))
>+     *     Optional<Path> p =
>+     *         uris.stream().filter(uri -> !isProcessedYet(uri))
>      *                       .findFirst()
>-     *                       .map(name -> new FileInputStream(name));
>+     *                       .map(Paths::get);
>      * }</pre>
>      *
>-     * Here, {@code findFirst} returns an {@code Optional<String>},
>and then
>-     * {@code map} returns an {@code Optional<FileInputStream>} for
>the desired
>-     * file if one exists.
>+     * Here, {@code findFirst} returns an {@code Optional<URI>}, and
>then
>+     * {@code map} returns an {@code Optional<Path>} for the desired
>+     * URI if one exists.
>      *
>   * @param mapper the mapping function to apply to a value, if present
>  * @param <U> The type of the value returned from the mapping function

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.