为什么 Java 8 类型推断在重载选择中不考虑 Lambda 抛出的异常？

Question

我有一个关于 lambda 及其相关异常签名的 Java 8 推理的问题。

如果我定义一些方法 foo:

public static <T> void foo(Supplier<T> supplier) {
    //some logic
    ...
}

然后我得到了能够在大多数情况下为给定的T 编写foo(() -> getTheT()); 的简洁明了的语义。但是，在此示例中，如果我的 getTheT 操作声明它为 throws Exception，则采用 Supplier 的 foo 方法不再编译：get 的 Supplier 方法签名不会引发异常。

似乎解决这个问题的一个不错的方法是重载 foo 以接受任一选项，重载定义为：

public static <T> void foo(ThrowingSupplier<T> supplier) {
   //same logic as other one
   ...
}

ThrowingSupplier 定义为

public interface ThrowingSupplier<T> {
   public T get() throws Exception;
}

通过这种方式，我们有一种供应商类型会引发异常，而另一种则不会。所需的语法是这样的：

foo(() -> operationWhichDoesntThrow()); //Doesn't throw, handled by Supplier
foo(() -> operationWhichThrows()); //Does throw, handled by ThrowingSupplier

但是，由于 lambda 类型不明确（可能无法在供应商和 ThrowingSupplier 之间解决），这会导致问题。像 foo((ThrowingSupplier)(() -> operationWhichThrows())); 那样进行显式转换会起作用，但它会消除所需语法的大部分简洁性。

我猜潜在的问题是：如果 Java 编译器能够解决我的一个 lambda 表达式不兼容的事实，因为它在仅限供应商的情况下抛出异常，为什么它不能使用相同的在辅助类型推断案例中推导出 lambda 类型的信息？

任何人都可以向我指出的任何信息或资源同样将不胜感激，因为我不太确定在哪里可以找到有关此事的更多信息。

谢谢！

Answer 1

如果它让你感觉更好，这个话题在 JSR-335 设计过程中确实是经过仔细考虑的。

问题不是“为什么它不能”，而是“我们为什么选择不这样做”。当我们发现多个可能适用的重载时，我们当然可以选择在每组签名下推测性地归因于 lambda 主体，并修剪那些 lambda 主体未能对其进行类型检查的候选者。

但是，我们得出的结论是，这样做可能弊大于利；这意味着，例如，在此规则下，对方法主体的微小更改可能会导致某些方法重载选择决策在用户不打算这样做的情况下默默地更改。最后，我们得出结论，使用方法主体中存在错误来丢弃可能适用的候选者会导致更多的混乱而不是好处，特别是考虑到有一个简单且安全的解决方法——提供目标类型。我们认为这里的可靠性和可预测性超过了最佳简洁性。

Answer 2

首先，您不必重载 :D - 重载从来都不是必需品；使用 2 个不同的方法名称，例如foo 和 fooX

其次，我不明白为什么您需要 2 种方法。如果您想以不同的方式处理已检查和未检查的异常，可以在运行时完成。要实现“异常透明”，可以这样做

interface SupplierX<T, X extends Throwable>
{
    T get() throws X;
}

<T, X extends Throwable> void foo(Supplier<T, X> supplier)  throws X { .. }


foo( ()->"" );  // throws RuntimeException

foo( ()->{ throw new IOException(); } );  // X=IOException

最后可以实现消除歧义 throw lambda 返回类型；编译器使用返回类型就像使用参数类型来选择最具体的方法一样。这给了我们将值与异常类型包装在一起的想法，如Result<T,X>，正如他们所说的“monad”。

interface Result<T, X extends Throwable>
{
    T get() throws X;
}

// error type embedded in return type, not in `throws` clause

static Result<String,        Exception> m1(){ return ()->{ throw new Exception();};  }
static Result<String, RuntimeException> m2(){ return ()->{ return "str";         };  }

  // better to have some factory method, e.g. return Result.success("str");

public static void main(String[] args)
{
    foo(()->m1());  // foo#2 is not applicable
    foo(()->m2());  // both applicable; foo#2 is more specific
}



interface S1<T> { T get(); }  

static <T> void foo(S1<Result<T, ? extends        Exception>> s)
{
    System.out.println("s1");}
}


interface S2<T> { T get(); }  // can't have two foo(S1) due to erasure

static <T> void foo(S2<Result<T, ? extends RuntimeException>> s)
{
    System.out.println("s2");
}

Answer 3

任何可以被接受为Supplier<T> 的lambda 也可以被接受为ThrowingSupplier<T>。以下编译：

public static interface ThrowingSupplier<T>{
    public T get() throws Exception;
}

public static <T> void foo(ThrowingSupplier<T> supplier) {

}

public static String getAString(){
    return "Hello";
}

public static String getAnotherString() throws Exception{
    return "World";
}

public static void main(String[] args) {
    foo(()->getAString());
    foo(()->getAnotherString());
} 

鉴于上述情况，您可能不需要这个，但如果foo 必须接受不抛出的Supplier<T>，您总是可以将抛出异常的方法包装在一个方法中将其清洗为未经检查的异常：

public static <T> void foo(Supplier<T> supplier) {

}

public static String getAString(){
    return "Hello";
}

public static String getAnotherString() throws Exception{
    return "World";
}

public static String getAnotherStringUnchecked(){
    try{
        return getAnotherString();
    } catch(Exception e){
        throw new RuntimeException("Error getting another string",e);
    }
}   

public static void main(String[] args) throws Exception{
    foo(()->getAString());
    foo(()->getAnotherStringUnchecked());
}