你必须在异常转义lambda之前捕获它:

s = s.filter(a -> {
    try {
        return a.isActive();
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
});

考虑到lambda不是在编写它的地方求值的，而是在JDK类中某个完全不相关的地方求值的。所以那将是被检查异常将被抛出的点，在那里它没有被声明。

你可以使用你的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) {
        sneakyThrow(e);
        return null; // Unreachable but needed to satisfy compiler
    }
}

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;
}

and you can expect to get an IOException thrown in your face, even though collect does not declare it. In most, but not all real-life cases you would want to just rethrow the exception, anyway, and handle it as a generic failure. In all those cases, nothing is lost in clarity or correctness. Just beware of those other cases, where you would actually want to react to the exception on the spot. The developer will not be made aware by the compiler that there is an IOException to catch there and the compiler will in fact complain if you try to catch it because we have fooled it into believing that no such exception can be thrown.

考虑到这个问题，我开发了一个小型库来处理受控异常和lambdas。自定义适配器允许您与现有的函数类型集成:

stream().map(unchecked(URI::new)) //with a static import

https://github.com/TouK/ThrowingFunction/

使用#propagate()方法。来自Sam Beran的Java 8 Blog的非guava实现示例:

public class Throwables {
    public interface ExceptionWrapper<E> {
        E wrap(Exception e);
    }

    public static <T> T propagate(Callable<T> callable) throws RuntimeException {
        return propagate(callable, RuntimeException::new);
    }

    public static <T, E extends Throwable> T propagate(Callable<T> callable, ExceptionWrapper<E> wrapper) throws E {
        try {
            return callable.call();
        } catch (RuntimeException e) {
            throw e;
        } catch (Exception e) {
            throw wrapper.wrap(e);
        }
    }
}

TLDR:尝试通过重构代码来避免这个问题:将“容易出错”的操作与“安全”的操作分开，只使用lambdas中的安全操作。

细节:

这并没有直接回答问题(有很多其他的答案)，但试图从一开始就避免这个问题:

根据我的经验，在Stream(或其他lambda表达式)中处理异常的需求通常来自这样一个事实，即异常被声明为从不应该抛出的方法抛出。这通常来自于将业务逻辑与输入和输出混合。你的帐户界面就是一个完美的例子:

interface Account {
    boolean isActive() throws IOException;
    String getNumber() throws IOException;
}

不要在每个getter上抛出IOException，考虑这样的设计:

interface AccountReader {
    Account readAccount(…) throws IOException;
}

interface Account {
    boolean isActive();
    String getNumber();
}

方法AccountReader.readAccount(…)可以从数据库或文件中读取帐户，如果未成功则抛出异常。它构造一个Account对象，该对象已经包含所有值，可以随时使用。由于这些值已经被readAccount(…)加载，getter不会抛出异常。因此，你可以在lambdas中自由地使用它们，而不需要包装、屏蔽或隐藏异常。

注意，您仍然需要处理readAccount(…)抛出的异常。毕竟，这就是异常存在的首要原因。但是假设readAccount(…)是在“其他地方”使用的，即在lambdas之外，在那里你可以使用Java提供的“正常”异常处理机制，即try-catch来处理它或throws来让它“冒泡”。

当然，不可能总是按照我描述的方式来做，但通常是这样的，它会导致更干净的代码(恕我直言):

Better separation of concerns and following single responsibility principle Less boilerplate: You don't have to clutter your code with throws IOException for no use but to satisfy the compiler Error handling: You handle the errors where they happen - when reading from a file or database - instead of somewhere in the middle of your business logic only because you want to get a fields value You may be able to make Account immutable and profit from the advantages thereof (e.g. thread safety) You don't need "dirty tricks" or workarounds to use Account in lambdas (e.g. in a Stream)

你也可以用lambdas传播你的静态疼痛，这样整个东西看起来可读:

s.filter(a -> propagate(a::isActive))

propagate在这里接收java.util.concurrent.Callable作为参数，并将调用期间捕获的任何异常转换为RuntimeException。在Guava中有一个类似的转换方法Throwables#propagate(Throwable)。

这个方法对于lambda方法链接来说是必不可少的，所以我希望有一天它会被添加到一个流行的库中，或者这种传播行为将是默认的。

public class PropagateExceptionsSample {
    // a simplified version of Throwables#propagate
    public static RuntimeException runtime(Throwable e) {
        if (e instanceof RuntimeException) {
            return (RuntimeException)e;
        }

        return new RuntimeException(e);
    }

    // this is a new one, n/a in public libs
    // Callable just suits as a functional interface in JDK throwing Exception 
    public static <V> V propagate(Callable<V> callable){
        try {
            return callable.call();
        } catch (Exception e) {
            throw runtime(e);
        }
    }

    public static void main(String[] args) {
        class Account{
            String name;    
            Account(String name) { this.name = name;}

            public boolean isActive() throws IOException {
                return name.startsWith("a");
            }
        }


        List<Account> accounts = new ArrayList<>(Arrays.asList(new Account("andrey"), new Account("angela"), new Account("pamela")));

        Stream<Account> s = accounts.stream();

        s
          .filter(a -> propagate(a::isActive))
          .map(a -> a.name)
          .forEach(System.out::println);
    }
}

你的例子可以写成:

import utils.stream.Unthrow;

class Bank{
   ....
   public Set<String> getActiveAccountNumbers() {
       return accounts.values().stream()
           .filter(a -> Unthrow.wrap(() -> a.isActive()))
           .map(a -> Unthrow.wrap(() -> a.getNumber()))
           .collect(Collectors.toSet());
   }
   ....
}

Unthrow类可以在这里https://github.com/SeregaLBN/StreamUnthrower