在这种情况下，我该如何处理 Function<T, R> 和 ellipsis/varargs？

Question

我的一个项目是throwing-lambdas；在其中，我旨在简化 Stream 中潜在 @FunctionalInterface 的使用，其在流中使用的唯一 "defect" 是它们抛出已检查的异常（就我而言，我宁愿不能从流中抛出已检查的异常这一事实称为缺陷，但这是另一回事了）。

所以，对于 Function<T, R>，我这样定义：

@FunctionalInterface
public interface ThrowingFunction<T, R>
    extends Function<T, R>
{
    R doApply(T t)
        throws Throwable;

    default R apply(T t)
    {
        try {
            return doApply(t);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable throwable) {
            throw new ThrownByLambdaException(throwable);
        }
    }
}

这允许我定义，例如：

final ThrowingFunction<Path, Path> = Path::toRealPath;

（为什么 Path::toRealPath...嗯，precisely because it has an ellipsis）。

不想在这里停下来，我希望能够写下类似的东西：

Throwing.function(Path::toRealPath).fallbackTo(Path::toAbsolutePath)

以上几乎可以工作...请继续阅读。

我也是这样定义的：

public abstract class Chainer<N, T extends N, C extends Chainer<N, T, C>>
{
    protected final T throwing;

    protected Chainer(final T throwing)
    {
        this.throwing = throwing;
    }

    public abstract C orTryWith(T other);

    public abstract <E extends RuntimeException> T orThrow(
        final Class<E> exclass);

    public abstract N fallbackTo(N fallback);

    public final <E extends RuntimeException> T as(final Class<E> exclass)
    {
        return orThrow(exclass);
    }
}

这是 Functions 的实现：

public final class ThrowingFunctionChain<T, R>
    extends Chainer<Function<T, R>, ThrowingFunction<T, R>, ThrowingFunctionChain<T, R>>
    implements ThrowingFunction<T, R>
{
    public ThrowingFunctionChain(final ThrowingFunction<T, R> function)
    {
        super(function);
    }

    @Override
    public R doApply(final T t)
        throws Throwable
    {
        return throwing.doApply(t);
    }

    @Override
    public ThrowingFunctionChain<T, R> orTryWith(
        final ThrowingFunction<T, R> other)
    {
        final ThrowingFunction<T, R> function = t -> {
            try {
                return throwing.doApply(t);
            } catch (Error | RuntimeException e) {
                throw e;
            } catch (Throwable ignored) {
                return other.doApply(t);
            }
        };

        return new ThrowingFunctionChain<>(function);
    }

    @Override
    public <E extends RuntimeException> ThrowingFunction<T, R> orThrow(
        final Class<E> exclass)
    {

        return t -> {
            try {
                return throwing.doApply(t);
            } catch (Error | RuntimeException e) {
                throw e;
            } catch (Throwable throwable) {
                throw  ThrowablesFactory.INSTANCE.get(exclass, throwable);
            }
        };
    }

    @Override
    public Function<T, R> fallbackTo(final Function<T, R> fallback)
    {
        return t -> {
            try {
                return doApply(t);
            } catch (Error | RuntimeException e) {
                throw e;
            } catch (Throwable ignored) {
                return fallback.apply(t);
            }
        };
    }
}

到目前为止一切顺利（虽然 IDEA fails to recognize the code of orTryWith() as valid，但那是另一回事了）。

我还定义了一个名为 Throwing 的实用程序 class，问题出在我作为测试编写的 class 的 main() 中：

public final class Throwing
{
    private Throwing()
    {
        throw new Error("nice try!");
    }

    public static <T, R> ThrowingFunctionChain<T, R> function(
        final ThrowingFunction<T, R> function)
    {
        return new ThrowingFunctionChain<>(function);
    }

    public static void main(final String... args)
    {
        // FAILS TO COMPILE
        final Function<Path, Path> f = function(Path::toRealPath)
            .fallbackTo(Path::toAbsolutePath);
    }
}

现在，上面代码的错误消息是：

Error:(29, 48) java: incompatible types: cannot infer type-variable(s) T,R
    (argument mismatch; invalid method reference
      method toRealPath in interface java.nio.file.Path cannot be applied to given types
        required: java.nio.file.LinkOption[]
        found: java.lang.Object
        reason: varargs mismatch; java.lang.Object cannot be converted to java.nio.file.LinkOption)
Error:(29, 49) java: invalid method reference
  non-static method toRealPath(java.nio.file.LinkOption...) cannot be referenced from a static context
Error:(30, 25) java: invalid method reference
  non-static method toAbsolutePath() cannot be referenced from a static context

我无法在这里诊断错误的确切原因，但对我来说，它看起来像是省略号妨碍了；事实上，如果我这样做：

    final ThrowingFunctionChain<Path, Path> f = function(Path::toRealPath);

    try (
        final Stream<Path> stream = Files.list(Paths.get(""));
    ) {
        stream.map(f.fallbackTo(Path::toAbsolutePath))
            .forEach(System.out::println);
    }

然后编译：所以这意味着 Stream.map() 确实承认结果是 Function...

那么为什么 Throwing.function(Path::toRealPath).fallbackTo(Path::toAbsolutePath) 不能编译？

Answer 1

正如 Holger 在 , the compiler is limited in its type inference when chaining methods 中所说的那样。只需提供一个显式类型参数

final Function<Path, Path> f = Throwing.<Path, Path>function(Path::toRealPath).fallbackTo(Path::toAbsolutePath);

Answer 2

其中一个问题是，作为可变参数方法，Path::toRealPath 具有以下不同的类型（作为隐式重载）用于目标类型推断目的：

Path toRealPath(Path a)（new LinkOption[0] 将由编译器隐式提供为第二个参数）。
Path toRealPath(Path a,LinkOption... b)（第二个参数直接）。
Path toRealPath(Path a,LinkOption[] b)（第二个参数直接）。
Path toRealPath(Path a,LinkOption b)（第二个参数将由编译器提供为 new LinkOption[1] { b }）。
Path toRealPath(Path a,LinkOption b,LinkOption c)（第二个参数将由编译器提供为 new LinkOption[2] { b, c }）。
Path toRealPath(Path a,LinkOption b,LinkOption c,LinkOption d)（第二个参数将由编译器提供为 new LinkOption[3] { b, c, d }）
Path toRealPath(Path a,LinkOption b,LinkOption c,LinkOption d,LinkOption e)（第二个参数将由编译器提供为 new LinkOption[3] { b, c, d, e }）
etc（第二个参数将由编译器提供为 new LinkOption[n] { b, c, d, e, ... }）

另一个是求解语句 Function<Path,Path> f= function(Path::toRealPath).fallbackTo(Path::toAbsolutePath) ; 隐含的类型方程需要推断 fallbackTo 的类型参数，因此它的 return 类型符合 Function<Path,Path>，然后function 的类型参数，所以它自己的 return 类型符合第一个。 Java 进行这种推断，但仅在涉及单个步骤时（参数参数，return 值到 return 类型，赋值中从右到左）。在 return 类型的情况下，推理链是无界的，通常有多个解决方案。

另一种方法是向编译器提供更多类型信息。例如：

Function<Path,Path> f= Throwing.<Path,Path>function(Path::toRealPath).fallbackTo(Path::toAbsolutePath) ;

或者通过创建临时变量，如：

ThrowingFunctionChain<Path,Path> stage1= function(Path::toRealPath) ;
Function<Path,Path> f= stage1.fallbackTo(Path::toAbsolutePath) ;

在这种情况下，stage1 的声明提供了附加信息。

从更普遍的角度来看，我不完全理解为什么人们在期望异常时会传播异常。我对 Optional<T> 或通过使用能够封装异常信息的非常小的扩展来完成或多或少相同的操作。您甚至可以使用 1.7 中引入的 "suppressed exception" 机制来处理隐式调用 close 方法期间发生的 try-with-resources 异常。问题似乎完全一样。代码非常简单，并且与 streams 和其他标准 Java SE 框架完全兼容。

Answer 3

你的代码片段

Function<Path, Path> f = function(Path::toRealPath).fallbackTo(Path::toAbsolutePath);

正在达到规范中包含的 Java 8 类型推断的限制，因此这不是编译器错误。当您链接方法调用时，目标类型不起作用。由于链中的第一个方法是可变参数方法，因此需要其目标类型才能找到预期的调用签名。这种情况类似于你写 p->p.toRealPath() 时，其中调用的参数数量是明确的，但 p 的类型是未知的。两者都不会在调用链中工作（除了最后一次调用）

这可以通过将第一次调用的类型明确化来解决，

Function<Path, Path> f = Throwing.<Path,Path>function(Path::toRealPath)
  .fallbackTo(Path::toAbsolutePath);

或

ThrowingFunctionChain<Path, Path> f0 = function(Path::toRealPath);
Function<Path, Path> f = f0.fallbackTo(Path::toAbsolutePath);

或

Function<Path, Path> f = function((Path p)->p.toRealPath())
    .fallbackTo(Path::toAbsolutePath);

或者通过将方法调用链转换为未链接的方法调用，如 described here:

public static <T, R> ThrowingFunctionChain<T, R> function(
    final ThrowingFunction<T, R> function)
{
    return new ThrowingFunctionChain<>(function);
}
public static <T, R> Function<T, R> function(
    final ThrowingFunction<T, R> function, Function<T, R> fallBack)
{
    return new ThrowingFunctionChain<>(function).fallbackTo(fallBack);
}
public static void main(final String... args)
{
    Function<Path, Path> f = function(Path::toRealPath, Path::toAbsolutePath);
}

当一个调用以另一个调用的结果为目标时，规范故意拒绝对两个调用进行类型推断，但如果相同的表达式只是另一个调用的参数，它就可以工作。

在这种情况下，我该如何处理 Function<T, R> 和 ellipsis/varargs？

How do I deal with Function<T, R> and ellipsis/varargs in this case?

java

lambda

variadic-functions

java-8

java-stream