inference of throws type parameters in SAMs

[Remi Forax]

On 10/31/2012 03:53 PM, Dan Smith wrote:
> This is on the radar for inference.  As you suggest, we would probably just choose RuntimeException in certain scenarios rather than using the upper bound.
>
> We have toyed with some more ambitious ideas for handling exceptions in lambda bodies, but those won't be part of Java 8.
>
> —Dan

yes, and my fear is that if we choose something different than Object 
now (like RuntimeException)
we will not be able to change the inference algorithm in Java 9.
At least with Object as default, we know that currently the inference 
fails so
we can provide a better one without creating incompatibilities.

Rémi

>
> On Oct 30, 2012, at 10:18 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> Hi all,
>>
>> I know this has been discussed before, but a long time has passed and
>> various inference algorithms have been tried in the meanwhile. So I
>> would like to ask whether current state is final. For example if I have
>> a functional interface like the following:
>>
>> public interface ThrowingFactory<T, E extends Throwable> {
>>      T make() throws E;
>> }
>>
>>
>> And a "hypothetical" method:
>>
>> public interface Stream<T> {
>>      <E extends Throwable> T findFirstOrElse(ThrowingFactory<T, E>
>> other) throws E;
>> }
>>
>>
>> Then the following program compiles OK:
>>
>>      public static void main(String... args) throws IOException
>>      {
>>          Stream<String> stream = null;
>>
>>          String first = stream.findFirstOrElse(() -> {throw new
>> IOException();});
>>      }
>>
>>
>> Which indicates that the inference algorithm does it's job correctly.
>> But the following program:
>>
>>      public static void main(String... args)
>>      {
>>          MyStream<String> stream = null;
>>
>>          String first = stream.findFirstOrElse(() -> "NO VALUE");
>>      }
>>
>>
>> Triggers the compilation failure:
>>
>> error: unreported exception Throwable; must be caught or declared to be
>> thrown
>>          String first = stream.findFirstOrElse(() -> "NO VALUE");
>>
>>
>> Regards, Peter
>>
>>
>>
>> P.S. If this worked, the controversial TypeThatMustNotBeNamed<T> which
>> is used as return type of 3 Stream methods could be replaced with 3*3=9
>> Stream methods that would more or less fit the main purpose of being
>> fluent. For example, current Stream.findFirst() would expand to:
>>
>> public interface Stream<T> {
>>      T findFirst() throws NoSuchElementException;
>>      T findFirstOrElse(T other);
>>      <E extends Throwable> T findFirstOrElse(ThrowingFactory<T, E>
>> other) throws E;
>> }
>>
>> Is this to much methods?
>>
>>
>>
>