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.san...@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.

Reply via email to