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

Question

我有一个关于Java8关于lambda及其相关异常签名的推断的问题。

如果我定义某个方法foo：

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

然后，我得到了一个很好和简洁的语义：在大多数情况下，可以为给定的t编写foo(()->getTheT())；。但是，在本例中，如果我的getthet操作声明它的抛出异常，那么我的foo方法将不再编译：get的Supplier方法签名不会抛出异常。

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类型不明确（可能无法在Supplier和ThrowingSupplier之间解决），这会引起一些问题。使用foo((ThrowingSupplier)(()->operationWhichThrows()))；进行显式强制转换可以工作，但它会消除所需语法的大部分简洁性。

任何信息或资源，任何人可以指出我将同样非常感谢，因为我只是不太确定在哪里寻找更多的信息关于这件事。

谢谢！

Answer 1

如果这让您感觉好一点，那么在JSR-335设计过程中确实仔细考虑了这个主题。

问题不是“为什么它不能”，而是“为什么我们选择不能”。当我们发现多个可能适用的重载时，我们当然可以选择推测性地将lambda体属性到每组签名下，并剪除lambda体未能进行类型检查的那些候选项。

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