java8 lamdba过滤id_Java 8：Lambda-Streams，按方法进行过滤（异常）

小编典典

你必须先捕获异常，然后才能转出lambda：

s = s.filter(a -> { try { return a.isActive(); }

catch (IOException e) { throw new UncheckedIOException(e); }}});

考虑以下事实：在JDK类中，lambda不在你编写的位置评估，而是在某些完全不相关的位置评估。这样便可以抛出该检查异常，并且在该位置不声明该异常。

你可以通过使用lambda的包装来处理它，该包装将已检查的异常转换为未检查的异常：

public static T uncheckCall(Callable 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 uncheckCall(Callable 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 void sneakyThrow(Throwable t) throws T {

throw (T) t;

}

IOException即使collect没有声明，你也可能会被扔到脸上。在大多数(但不是全部)实际情况下，无论如何，你都只想抛出异常，并将其作为一般故障进行处理。在所有这些情况下，清晰度或正确性都不会丢失。只是要提防那些其他情况，你实际上想在现场对异常做出反应。编译器不会使开发人员意识到存在一个IOException陷阱，实际上，如果你尝试捕获它，编译器实际上会抱怨，因为我们欺骗了它以为不会抛出此类异常。

2020-03-15