你必须先捕获异常，然后才能转出lambda：
s = s.filter(a -> { try { return a.isActive(); } catch (IOException e) { throw new UncheckedIOException(e); }}});考虑以下事实：在JDK类中，lambda不在你编写的位置评估，而是在某些完全不相关的位置评估。这样便可以抛出该检查异常，并且在该位置不声明该异常。
你可以通过使用lambda的包装来处理它，该包装将已检查的异常转换为未检查的异常：
public static <T> T uncheckCall(Callable<T> callable) { try { return callable.call(); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new RuntimeException(e); }}你的示例将写为
return s.filter(a -> uncheckCall(a::isActive)) .map(Account::getNumber) .collect(toSet());
在我的项目中，我无需包装即可处理此问题；取而代之的是，我使用一种有效地缓解编译器对异常检查的方法。不用说，应该小心处理，项目中的每个人都必须意识到，未经声明的异常可能会出现在经过检查的异常中。这是管道代码：
public static <T> T uncheckCall(Callable<T> callable) { try { return callable.call(); } catch (Exception e) { return sneakyThrow(e); }}public static void uncheckRun(RunnableExc r) { try { r.run(); } catch (Exception e) { sneakyThrow(e); }}public interface RunnableExc { void run() throws Exception; }@SuppressWarnings("unchecked")private static <T extends Throwable> void sneakyThrow(Throwable t) throws T { throw (T) t;}IOException即使
collect没有声明，你也可能会被扔到脸上。在大多数（但不是全部）实际情况下，无论如何，你都只想抛出异常，并将其作为一般故障进行处理。在所有这些情况下，清晰度或正确性都不会丢失。只是要提防那些其他情况，你实际上想在现场对异常做出反应。编译器不会使开发人员意识到存在一个
IOException陷阱，实际上，如果你尝试捕获它，编译器实际上会抱怨，因为我们欺骗了它以为不会抛出此类异常。
