这样做是不安全的。你可以作弊，但你的程序坏了，这将不可避免地反过来伤害别人(应该是你，但我们的作弊经常会伤害到别人)。

这里有一个稍微安全一点的方法(但我仍然不推荐这样做)。

class WrappedException extends RuntimeException {
    Throwable cause;

    WrappedException(Throwable cause) { this.cause = cause; }
}

static WrappedException throwWrapped(Throwable t) {
    throw new WrappedException(t);
}

try 
    source.stream()
          .filter(e -> { ... try { ... } catch (IOException e) { throwWrapped(e); } ... })
          ...
}
catch (WrappedException w) {
    throw (IOException) w.cause;
}

在这里，您要做的是捕获lambda中的异常，从流管道中抛出一个信号，表明计算异常失败，捕获信号，并对该信号进行操作以抛出底层异常。关键是您总是捕获合成异常，而不是在没有声明抛出异常的情况下允许已检查异常泄漏。

你不能。

然而，你可能想要看看我的一个项目，它可以让你更容易地操纵这种“投掷lambda”。

在你的情况下，你可以这样做:

import static com.github.fge.lambdas.functions.Functions.wrap;

final ThrowingFunction<String, Class<?>> f = wrap(Class::forName);

List<Class> classes =
    Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
          .map(f.orThrow(MyException.class))
          .collect(Collectors.toList());

并捕获MyException。

这是一个例子。另一个例子是你可以. orreturn()一些默认值。

请注意，这仍然是一项正在进行的工作，更多的是来。更好的名字，更多的功能等等。

对于你的问题，简单的答案是:你不能，至少不能直接。这不是你的错。甲骨文搞砸了。他们坚持受控异常的概念，但在设计功能接口、流、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之间交互的工作。

也许，更好、更实用的方法是包装异常并在流中进一步传播它们。以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中几乎所有泛型异常都被视为未检查的。

在使用Stream时，我同意上面的评论。映射你被限制实现不抛出异常的函数。

然而，你可以创建自己的FunctionalInterface，抛出如下..

@FunctionalInterface
public interface UseInstance<T, X extends Throwable> {
  void accept(T instance) throws X;
}

然后使用Lambdas或引用实现它，如下所示。

import java.io.FileWriter;
import java.io.IOException;

//lambda expressions and the execute around method (EAM) pattern to
//manage resources

public class FileWriterEAM  {
  private final FileWriter writer;

  private FileWriterEAM(final String fileName) throws IOException {
    writer = new FileWriter(fileName);
  }
  private void close() throws IOException {
    System.out.println("close called automatically...");
    writer.close();
  }
  public void writeStuff(final String message) throws IOException {
    writer.write(message);
  }
  //...

  public static void use(final String fileName, final UseInstance<FileWriterEAM, IOException> block) throws IOException {

    final FileWriterEAM writerEAM = new FileWriterEAM(fileName);    
    try {
      block.accept(writerEAM);
    } finally {
      writerEAM.close();
    }
  }

  public static void main(final String[] args) throws IOException {

    FileWriterEAM.use("eam.txt", writerEAM -> writerEAM.writeStuff("sweet"));

    FileWriterEAM.use("eam2.txt", writerEAM -> {
        writerEAM.writeStuff("how");
        writerEAM.writeStuff("sweet");      
      });

    FileWriterEAM.use("eam3.txt", FileWriterEAM::writeIt);     

  }


 void writeIt() throws IOException{
     this.writeStuff("How ");
     this.writeStuff("sweet ");
     this.writeStuff("it is");

 }

}

您还可以编写一个包装器方法来包装未检查的异常，甚至使用表示另一个功能接口的附加参数(具有相同的返回类型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;
}