只要使用Lombok的@SneakyThrows就可以了。

Christian Hujer已经详细解释了为什么严格来说，由于Java的限制，从流中抛出受控异常是不可能的。

其他一些回答解释了一些技巧，可以绕过语言的限制，但仍然能够满足抛出“检查异常本身，并且不向流中添加丑陋的try/catch”的要求，其中一些需要额外的数十行样板文件。

我要强调的是另一个选项，在我看来，这个选项比其他选项干净得多:Lombok的@SneakyThrows。这个问题在其他答案中也提到过，但有很多不必要的细节。

生成的代码非常简单:

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes =
        Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
                .map(className -> getClass(className))
                .collect(Collectors.toList());
    return classes;
}

@SneakyThrows                                 // <= this is the only new code
private Class<?> getClass(String className) {
    return Class.forName(className);
}

我们只需要一个提取方法重构(由IDE完成)和一行额外的@SneakyThrows。注释负责添加所有样板文件，以确保您可以抛出检查过的异常，而无需将其包装在RuntimeException中，也无需显式声明它。

你可以用apache commons-lang3库来实现。

https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/function/Failable.html

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes =
            Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
                    .map(Failable.asFunction(Class::forName))
                    .collect(Collectors.toList());
    return classes;
}

我写了一个扩展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());
}

我使用这种包装异常:

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或其他东西。

这个答案类似于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
        }

对于你的问题，简单的答案是:你不能，至少不能直接。这不是你的错。甲骨文搞砸了。他们坚持受控异常的概念，但在设计功能接口、流、lambda等时却总是忘记了受控异常。这对罗伯特·c·马丁(Robert C. Martin)等专家来说都是好消息，他把受控异常称为失败的实验。

在我看来，这是API中的一个大错误，而语言规范中的一个小错误。

API中的缺陷在于，它没有提供转发已检查异常的功能，而这实际上对函数式编程非常有意义。正如我将在下面演示的那样，这样的设施是很容易实现的。

语言规范中的错误在于，它不允许类型参数推断类型列表而不是单个类型，只要类型参数只在允许类型列表的情况下使用(throws子句)。

作为Java程序员，我们的期望是编译以下代码:

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class CheckedStream {
    // List variant to demonstrate what we actually had before refactoring.
    public List<Class> getClasses(final List<String> names) throws ClassNotFoundException {
        final List<Class> classes = new ArrayList<>();
        for (final String name : names)
            classes.add(Class.forName(name));
        return classes;
    }

    // The Stream function which we want to compile.
    public Stream<Class> getClasses(final Stream<String> names) throws ClassNotFoundException {
        return names.map(Class::forName);
    }
}

然而，它给出:

cher@armor1:~/playground/Java/checkedStream$ javac CheckedStream.java 
CheckedStream.java:13: error: incompatible thrown types ClassNotFoundException in method reference
        return names.map(Class::forName);
                         ^
1 error

函数接口的定义方式目前阻止编译器转发异常——没有声明告诉Stream.map()如果Function.apply()抛出E, Stream.map()也会抛出E。

缺少的是用于传递已检查异常的类型参数的声明。下面的代码展示了如何使用当前语法声明这种传递类型参数。除了标记行中的特殊情况(这是下面讨论的限制)，此代码将按预期进行编译和运行。

import java.io.IOException;
interface Function<T, R, E extends Throwable> {
    // Declare you throw E, whatever that is.
    R apply(T t) throws E;
}   

interface Stream<T> {
    // Pass through E, whatever mapper defined for E.
    <R, E extends Throwable> Stream<R> map(Function<? super T, ? extends R, E> mapper) throws E;
}   

class Main {
    public static void main(final String... args) throws ClassNotFoundException {
        final Stream<String> s = null;

        // Works: E is ClassNotFoundException.
        s.map(Class::forName);

        // Works: E is RuntimeException (probably).
        s.map(Main::convertClass);

        // Works: E is ClassNotFoundException.
        s.map(Main::throwSome);

        // Doesn't work: E is Exception.
        s.map(Main::throwSomeMore);  // error: unreported exception Exception; must be caught or declared to be thrown
    }   
    
    public static Class convertClass(final String s) {
        return Main.class;
    }   

    static class FooException extends ClassNotFoundException {}

    static class BarException extends ClassNotFoundException {}

    public static Class throwSome(final String s) throws FooException, BarException {
        throw new FooException();
    }   

    public static Class throwSomeMore(final String s) throws ClassNotFoundException, IOException  {
        throw new FooException();
    }   
}   

在throwSomeMore的情况下，我们希望IOException被错过，但它实际上错过了Exception。

这并不完美，因为类型推断似乎是在寻找单一类型，即使在异常的情况下也是如此。因为类型推断需要单一类型，E需要解析为ClassNotFoundException和IOException的公共超，即Exception。

需要对类型推断的定义进行调整，以便在允许使用类型列表(throws子句)的地方使用类型形参时，编译器可以查找多个类型。然后，编译器报告的异常类型将与引用方法的已检查异常的原始throws声明一样具体，而不是单一的全能超类型。

坏消息是，这意味着甲骨文搞砸了。当然，它们不会破坏用户土地代码，但是向现有功能接口引入异常类型参数会破坏显式使用这些接口的所有用户土地代码的编译。他们必须发明一些新的语法来解决这个问题。

更糟糕的消息是Brian Goetz在2010年就已经讨论过这个话题了(https://blogs.oracle.com/briangoetz/entry/exception_transparency_in_java, http://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/001484.html)，但我被告知这个调查最终没有成功，而且据我所知，Oracle目前没有减轻受控异常和lambdas之间交互的工作。