hg: lambda/lambda/jdk: Add BufferedReader.lines

[Brian Goetz]

Some background...

There were many ways to approach the issue of exceptions in lambdas. 
The approach we took in the end -- which is largely "ignore them" for 
the most part, making some small concessions for IOException -- is a 
pragmatic choice that covers most of the interesting use cases while 
minimizing intrusion and accidental complexity.

Without any sort of exception transparency, we'd have to have both 
exception-bearing and non-exception-bearing versions of all the 
functional interfaces (and the methods that take them).  As if this 
weren't bad enough, if you look at the dimensions of specialization for 
functional interfaces, it explodes:

  - basic kind (Predicate, Function, etc)
  - arity specializations (e.g., two-arg predicate)
  - primitive specializations (e.g., IntPredicate)
  - exceptions or not
  - serializable or not

This rapidly spirals out of control.  Pruning the exception and 
serialization dimensions from this restores things to the "barely 
manageable" level.

We explored multiple options for exception transparency and found none 
of them to offer the right balance of power and complexity, especially 
with respect to compatibly evolving existing constructs like Iterator. 
We have some interesting ideas in this category that we may come back to 
in a future round.

When we looked at the use cases where exceptions really intruded into 
streams, they were *all* IOException thrown in situations where any sort 
of fine-grained recovery was dubious.  So the pragmatic solution for the 
current round was "do something simple for IOException", and focus the 
remainder of our limited time on higher-value things.

On 11/12/2012 4:01 AM, Olexandr Demura wrote:
> Exceptional streams looks to me simply like one more StreamShape,
> dual to Mapping<K, V> stream shape - some analogue to `Either A B`.
> If concept of Map Stream is viable yet, of course.
>
> BTW, java implicitly have that `shape` for years (:
> Callable<T> ~= () -> (T | Exception)
>
> e.g. what if Optional<T> doesn't exist.
>
> T reduce(T base, BinaryOperator<T> op);
> Optional<T> reduce(BinaryOperator<T> op);
> ->
> <X> T reduce(BinaryOperator<T> op, Factory<X> otherwise) throws X;
>
> Optional<T> findFirst();
> Optional<T> findAny();
> ->
> <X> T findFirst(Factory<X> otherwise) throws X;
> <X> T findAny(Factory<X> otherwise) throws X;
>
> 2012/11/12 Zhong Yu <zhong.j.yu at gmail.com <mailto:zhong.j.yu at gmail.com>>
>
>
>     UncheckedIOException would also be useful in many applications where
>     IO exceptions aren't expected to occur, and it would have been better
>     if they are unchecked. Now programmers can use UncheckedIOException to
>     convert IO exceptions to uncheck exceptions.
>
>     However, why not have a general UncheckedException, so that we don't
>     need to invent UncheckSQLException, UncheckedReflectionException etc.
>     We can use RuntimeException as the wrapper now, but a dedicated
>     UncheckedException can be more clear that this is just a wrapper of
>     the actual exception.
>
>     Zhong Yu
>
>