处理map操作抛出的受控异常的唯一内置方法是将它们封装在CompletableFuture中。(如果你不需要保留异常，一个Optional是一个更简单的选择。)这些类旨在允许您以函数的方式表示偶然操作。

需要几个重要的帮助器方法，但是您可以得到相对简洁的代码，同时仍然明显地表明流的结果取决于映射操作是否成功完成。这是它的样子:

    CompletableFuture<List<Class<?>>> classes =
            Stream.of("java.lang.String", "java.lang.Integer", "java.lang.Double")
                  .map(MonadUtils.applyOrDie(Class::forName))
                  .map(cfc -> cfc.thenApply(Class::getSuperclass))
                  .collect(MonadUtils.cfCollector(ArrayList::new,
                                                  List::add,
                                                  (List<Class<?>> l1, List<Class<?>> l2) -> { l1.addAll(l2); return l1; },
                                                  x -> x));
    classes.thenAccept(System.out::println)
           .exceptionally(t -> { System.out.println("unable to get class: " + t); return null; });

这将产生以下输出:

[class java.lang.Object, class java.lang.Number, class java.lang.Number]

applyOrDie方法接受一个抛出异常的函数，并将其转换为一个返回已经完成的CompletableFuture的函数——要么用原始函数的结果正常完成，要么用抛出的异常异常完成。

第二个映射操作说明您现在得到了一个Stream<CompletableFuture<T>>，而不仅仅是一个Stream<T>。如果上游操作成功，CompletableFuture只负责执行该操作。API可以显式地做到这一点，但相对来说并不痛苦。

直到您到达收集阶段。这就是我们需要一个非常重要的助手方法的地方。我们希望“提升”一个正常的收集操作(在本例中是toList())在CompletableFuture——cfCollector()中，我们可以使用一个供应商、累加器、组合器和完成器来实现这一点，而不需要知道关于CompletableFuture的任何事情。

助手方法可以在GitHub上我的MonadUtils类中找到，这仍然是一项正在进行的工作。

您还可以编写一个包装器方法来包装未检查的异常，甚至使用表示另一个功能接口的附加参数(具有相同的返回类型R)来增强包装器。 在这种情况下，您可以传递一个函数，该函数将在异常情况下执行并返回。 请看下面的例子:

private void run() {
    List<String> list = Stream.of(1, 2, 3, 4).map(wrapper(i ->
            String.valueOf(++i / 0), i -> String.valueOf(++i))).collect(Collectors.toList());
    System.out.println(list.toString());
}

private <T, R, E extends Exception> Function<T, R> wrapper(ThrowingFunction<T, R, E> function, 
Function<T, R> onException) {
    return i -> {
        try {
            return function.apply(i);
        } catch (ArithmeticException e) {
            System.out.println("Exception: " + i);
            return onException.apply(i);
        } catch (Exception e) {
            System.out.println("Other: " + i);
            return onException.apply(i);
        }
    };
}

@FunctionalInterface
interface ThrowingFunction<T, R, E extends Exception> {
    R apply(T t) throws E;
}

我使用这种包装异常:

public class CheckedExceptionWrapper extends RuntimeException {
    ...
    public <T extends Exception> CheckedExceptionWrapper rethrow() throws T {
        throw (T) getCause();
    }
}

它需要静态处理这些异常:

void method() throws IOException, ServletException {
    try { 
        list.stream().forEach(object -> {
            ...
            throw new CheckedExceptionWrapper(e);
            ...            
        });
    } catch (CheckedExceptionWrapper e){
        e.<IOException>rethrow();
        e.<ServletExcepion>rethrow();
    }
}

在网上试试!

尽管在第一次rethrow()调用期间无论如何都会重新抛出异常(哦，Java泛型…)，这种方式允许获得可能异常的严格静态定义(需要在抛出中声明它们)。不需要instanceof或其他东西。

处理map操作抛出的受控异常的唯一内置方法是将它们封装在CompletableFuture中。(如果你不需要保留异常，一个Optional是一个更简单的选择。)这些类旨在允许您以函数的方式表示偶然操作。

需要几个重要的帮助器方法，但是您可以得到相对简洁的代码，同时仍然明显地表明流的结果取决于映射操作是否成功完成。这是它的样子:

    CompletableFuture<List<Class<?>>> classes =
            Stream.of("java.lang.String", "java.lang.Integer", "java.lang.Double")
                  .map(MonadUtils.applyOrDie(Class::forName))
                  .map(cfc -> cfc.thenApply(Class::getSuperclass))
                  .collect(MonadUtils.cfCollector(ArrayList::new,
                                                  List::add,
                                                  (List<Class<?>> l1, List<Class<?>> l2) -> { l1.addAll(l2); return l1; },
                                                  x -> x));
    classes.thenAccept(System.out::println)
           .exceptionally(t -> { System.out.println("unable to get class: " + t); return null; });

这将产生以下输出:

[class java.lang.Object, class java.lang.Number, class java.lang.Number]

applyOrDie方法接受一个抛出异常的函数，并将其转换为一个返回已经完成的CompletableFuture的函数——要么用原始函数的结果正常完成，要么用抛出的异常异常完成。

第二个映射操作说明您现在得到了一个Stream<CompletableFuture<T>>，而不仅仅是一个Stream<T>。如果上游操作成功，CompletableFuture只负责执行该操作。API可以显式地做到这一点，但相对来说并不痛苦。

直到您到达收集阶段。这就是我们需要一个非常重要的助手方法的地方。我们希望“提升”一个正常的收集操作(在本例中是toList())在CompletableFuture——cfCollector()中，我们可以使用一个供应商、累加器、组合器和完成器来实现这一点，而不需要知道关于CompletableFuture的任何事情。

助手方法可以在GitHub上我的MonadUtils类中找到，这仍然是一项正在进行的工作。

我认为这种方法是正确的:

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes;
    try {
        classes = Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String").map(className -> {
            try {
                return Class.forName(className);
            } catch (ClassNotFoundException e) {
                throw new UndeclaredThrowableException(e);
            }
        }).collect(Collectors.toList());
    } catch (UndeclaredThrowableException e) {
        if (e.getCause() instanceof ClassNotFoundException) {
            throw (ClassNotFoundException) e.getCause();
        } else {
            // this should never happen
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
    return classes;
}

将检查过的异常包装在一个unclaredthrowableexception(这是该异常的用例)的Callable内部，并在外部将其展开。

是的，我觉得它很难看，我建议在这种情况下不要使用lambdas，而是退回到一个好的旧循环，除非您正在使用并行流，并且并行化带来了客观的好处，可以证明代码的不可读性是正确的。

正如许多人所指出的那样，有解决这种情况的解决方案，我希望其中一个解决方案能够出现在Java的未来版本中。

我写了一个扩展Stream API的库，以允许抛出受控异常。它使用了Brian Goetz的技巧。

您的代码将变成

public List<Class> getClasses() throws ClassNotFoundException {     
    Stream<String> classNames = 
        Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String");

    return ThrowingStream.of(classNames, ClassNotFoundException.class)
               .map(Class::forName)
               .collect(Collectors.toList());
}