是否可以声明某个供应商需要抛出异常？

Question

所以我正在尝试重构以下代码：

/**
 * Returns the duration from the config file.
 * 
 * @return  The duration.
 */
private Duration durationFromConfig() {
    try {
        return durationFromConfigInner();
    } catch (IOException ex) {
        throw new IllegalStateException("The config file (\"" + configFile + "\") has not been found.");
    }
}

/**
 * Returns the duration from the config file.
 * 
 * Searches the log file for the first line indicating the config entry for this instance.
 * 
 * @return  The duration.
 * @throws FileNotFoundException If the config file has not been found.
 */
private Duration durationFromConfigInner() throws IOException {
    String entryKey = subClass.getSimpleName();
    configLastModified = Files.getLastModifiedTime(configFile);
    String entryValue = ConfigFileUtils.readFileEntry(configFile, entryKey);
    return Duration.of(entryValue);
}

我想出了下面的开头：

private <T> T getFromConfig(final Supplier<T> supplier) {
    try {
        return supplier.get();
    } catch (IOException ex) {
        throw new IllegalStateException("The config file (\"" + configFile + "\") has not been found.");
    }
}

但是，它不编译（显然），因为supplier不能抛出IOException。有什么方法可以将它添加到GetFromConfig的方法声明中吗？

还是只有这样才能做到？

@FunctionalInterface
public interface SupplierWithIO<T> extends Supplier<T> {
    @Override
    @Deprecated
    default public T get() {
        throw new UnsupportedOperationException();
    }

    public T getWithIO() throws IOException;
}

更新后，我才意识到supplier接口非常简单，因为它只有get()方法。我扩展supplier的最初原因是优先于基本功能，例如默认方法。

Answer 1

在lambda邮件列表中对此进行了详细讨论。正如您所看到的，Brian Goetz在那里建议，另一种选择是编写您自己的组合子：

或者您可以编写自己的简单组合子：

static<T> Block<T> exceptionWrappingBlock(Block<T> b) {
     return e -> {
         try { b.accept(e); }
         catch (Exception e) { throw new RTE(e); }
     };
}

你可以只写一次，只需花更少的时间来写你最初的电子邮件。对于您使用的每种SAM,同样地也要使用一次。

我宁愿我们把它看成是“满99%的玻璃杯”，而不是另一个选择。并不是所有的问题都需要新的语言特性作为解决方案。（更不用说新的语言特性总是会引起新的问题。）

在那个时代，消费者接口被称为块。

EG讨论了对此问题的额外语言和库支持，最后认为这是一个糟糕的成本/收益权衡。

基于库的解决方案导致SAM类型的2倍爆炸（例外与不例外），这些爆炸与现有的基元专门化组合爆炸交互不良。

现有的基于语言的解决方案是复杂度/价值权衡的输家。尽管有一些替代的解决方案，我们将继续探索--尽管显然不是8的，也可能不是9的。