也许，更好、更实用的方法是包装异常并在流中进一步传播它们。以Vavr的Try类型为例。

例子:

interface CheckedFunction<I, O> {
    O apply(I i) throws Exception; }

static <I, O> Function<I, O> unchecked(CheckedFunction<I, O> f) {
    return i -> {
        try {
            return f.apply(i);
        } catch(Exception ex) {

            throw new RuntimeException(ex);
        }
    } }

fileNamesToRead.map(unchecked(file -> Files.readAllLines(file)))

OR

@SuppressWarnings("unchecked")
private static <T, E extends Exception> T throwUnchecked(Exception e) throws E {
    throw (E) e;
}

static <I, O> Function<I, O> unchecked(CheckedFunction<I, O> f) {
    return arg -> {
        try {
            return f.apply(arg);
        } catch(Exception ex) {
            return throwUnchecked(ex);
        }
    };
}

第二个实现避免将异常包装在RuntimeException中。throwUnchecked可以工作，因为在java中几乎所有泛型异常都被视为未检查的。

这个答案类似于17，但避免了包装器异常定义:

List test = new ArrayList();
        try {
            test.forEach(obj -> {

                //let say some functionality throws an exception
                try {
                    throw new IOException("test");
                }
                catch(Exception e) {
                    throw new RuntimeException(e);
                }
            });
        }
        catch (RuntimeException re) {
            if(re.getCause() instanceof IOException) {
                //do your logic for catching checked
            }
            else 
                throw re; // it might be that there is real runtime exception
        }

这是原来问题的不同观点或解决方案。在这里，我展示了我们有一个选项来编写只处理有效值子集的代码，并有一个选项来检测和处理抛出异常时的情况。

    @Test
    public void getClasses() {

        String[] classNames = {"java.lang.Object", "java.lang.Integer", "java.lang.Foo"};
        List<Class> classes =
                Stream.of(classNames)
                        .map(className -> {
                            try {
                                return Class.forName(className);
                            } catch (ClassNotFoundException e) {
                                // log the error
                                return null;
                            }
                        })
                        .filter(c -> c != null)
                        .collect(Collectors.toList());

        if (classes.size() != classNames.length) {
            // add your error handling here if needed or process only the resulting list
            System.out.println("Did not process all class names");
        }

        classes.forEach(System.out::println);
    }

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

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的未来版本中。

处理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类中找到，这仍然是一项正在进行的工作。

只要使用任何一个NoException(我的项目)，jOOλ的Unchecked, throw -lambdas, Throwable接口或Faux Pas。

// NoException
stream.map(Exceptions.sneak().function(Class::forName));

// jOOλ
stream.map(Unchecked.function(Class::forName));

// throwing-lambdas
stream.map(Throwing.function(Class::forName).sneakyThrow());

// Throwable interfaces
stream.map(FunctionWithThrowable.aFunctionThatUnsafelyThrowsUnchecked(Class::forName));

// Faux Pas
stream.map(FauxPas.throwingFunction(Class::forName));