重新打包流中的异常

Java 8已有两年的历史了，但是仍然存在社区尚未为其开发好的解决方案的用例，甚至边缘用例。如何处理流管道中的已检查异常就是这样的问题之一。 Stream操作接受的功能接口不允许实现抛出已检查的异常，但是我们可能要调用许多方法。显然，这里存在一种紧张关系，许多开发人员都曾遇到过这种紧张关系。

我想在简短的系列文章中探讨这个主题：

重新打包流中的异常

重新打包异常以便抛出它们，而编译器不会抱怨它。

处理流中的异常

可以通过延迟错误处理来现场捕获并处理异常。

流中抛出异常

毕竟如何通过引发异常来处理延迟的错误。

我的主要目标是提出各种解决方案，并且在理想情况下，建立使讨论更容易的通用术语。我还将对我的建议发表评论，并添加自己的评估意见-尽管这是次要的，但我希望它不会偏离主要目标：将想法付诸实践。

第一篇文章将研究重新打包异常，以便编译器停止抱怨。

设置场景

基本场景是流的每个频繁用户遇到的一种或多种形式：您想在流的中间操作之一中使用的方法将引发检查的异常。

在本文中，我将假定您正在尝试将字符串流解析为用户流：

Stream<User> parse(Stream<String> strings) {return strings.map(User::parse);
}

（如果您不打算将流作为参数或返回值，请假设整个流管道都在方法的范围之内。以下两种方法都可以应用，但是如果您对流中的整个流进行处理，则某些评估会有所不同。点。）

不幸的是， User::parse可以抛出ParseException ：

public class User {public static User parse(String userString) throws ParseException {// ...}}

这导致编译器抱怨方法参考User::parse “未处理的异常：java.text.ParseException” 。现在做什么？

在我们研究该问题的解决方案之前，我想指出一点：我不认为Stream API与检查异常的不兼容性是可以通过其他设计克服的。在某个时候，我可能会写一个更长的帖子来解释这一点，但是简短的版本是这样的：如果功能接口方法可能引发检查异常，那么将没有一种将流与惰性结合在一起的令人愉悦的方法，因为它将是终端操作最终抛出该异常。

但是我们可以充分利用可以引发异常的函数，因此让我们在介绍该接口时对其进行介绍：

@FunctionalInterface
interface CheckedFunction<T, R, EX extends Exception> {R apply(T element) throws EX;}

这使我们可以将User::parse分配给CheckedFunction<String ， User, ParseException> 。请注意，异常的类型是通用的，稍后将派上用场。

重新打包流中的异常

那么，您真的必须处理例外情况吗？不知道，您能不能使问题解决？令人惊讶的答案是“是的，您可以。” 是否应该拭目以待……

包装未检查的异常

给定一个引发检查异常的函数，将其转换为引发未检查异常的函数非常容易：

Stream<User> parse(Stream<String> strings) {return strings.map(uncheckException(User::parse))
}<T, R> Function<T, R> uncheckException(CheckedFunction<T, R, Exception> function) {return element -> {try {return function.apply(element);} catch (Exception ex) {// thanks to Christian Schneider for pointing out// that unchecked exceptions need not be wrapped againif (ex instanceof RuntimeException)throw (RuntimeException) ex;elsethrow new RuntimeException(ex);}};
}

这实际上还不错。而且，无论如何，如果您更喜欢未检查的异常，那么这将更具吸引力。另一方面，如果您重视检查的异常（对于您期望的事情可能会出错，例如错误的输入）与未检查的异常（对于实现错误）之间的区别，那么这将使您不寒而栗。

在任何情况下，流的最终使用者都必须意识到可能会引发异常，这时需要与测试或文档进行通信，这两者都比编译器更容易忽略。感觉就像在小河里藏了一颗炸弹。

最后，请注意，这会在第一个错误发生时立即中止流-可能会或可能不会发生的事情。如果该方法返回一个流而不是使用它，则很难确定是否可行，因为不同的调用者可能有不同的要求。

偷偷摸摸的异常

解决整个问题的另一种方法是“偷偷地”抛出异常。该技术使用泛型来混淆编译器，并使用@SuppressWarnings使其剩余的投诉静音。

Stream<User> parse(Stream<String> strings) {return strings.map(hideException(User::parse));
}<T, R> Function<T, R> hideException(CheckedFunction<T, R, Exception> function) {return element -> {try {return function.apply(element);} catch (Exception ex) {return sneakyThrow(ex);}};
}@SuppressWarnings("unchecked")
<E extends Throwable, T> T sneakyThrow(Throwable t) throws E {throw (E) t;
}

嗯，什么？如所承诺的， sneakyThrow方法使用泛型来欺骗编译器以sneakyThrow未经检查的异常而不声明它。然后hideException使用它来捕获CheckedFunction可能抛出的任何异常，然后hideException将其重新抛出。（如果您使用的是Lombok，请查看其@SneakyThrows批注。）

我认为这是非常冒险的举动。对于它，它仍然在小河中隐藏了一颗炸弹。但是，它走得更远，这使得炸弹难以妥善化解。您是否曾经尝试捕获未使用throws子句声明的检查异常？

try {userStrings.stream().map(hideException(User::parse));.forEach(System.out::println);
// compile error because ParseException
// is not declared as being thrown
} catch (ParseException ex) {// handle exception
}

无法工作，因为编译器在没有方法实际抛出ParseException的假设下运行。相反，您必须捕获Exception ，过滤掉ParseException并重新抛出其他所有内容。

哇，真烂！

不幸的是，这种技术出现在StackOverflow答案中，当寻找Java流异常处理时，它在Google上的排名非常高。公平地说，答案包含免责声明，但恐怕它可能会经常被忽略：

不用说，应该谨慎处理，项目中的每个人都必须意识到，未经声明的异常可能会出现在经过检查的异常中。

但是，正如我们已经看到的那样，没有很好的方法来声明/捕获这样的异常，所以我要说的是：

这是一个不错的实验，但从未真正做到！如果确实要抛出，请包装运行时异常。

电梯例外

偷偷摸摸的问题是，它使流的消费者感到惊讶，并且即使他们克服了这种惊讶，也很难处理该异常。对于后者，至少有一个出路。考虑以下功能：

<T, R, EX extends Exception> Function<T, R> liftException(CheckedFunction<T, R, EX> function) throws EX {return hideException(function);
}

它与hideException完全相同，但是声明它抛出EX。为什么会有帮助？因为可以通过这种方式使编译器理解可能会抛出检查异常：

Stream<User> parse(Stream<String> strings) {return strings// does not compile because `liftException`// throws ParseException but it is unhandled.map(liftException(User::parse));
}

问题是， liftException的主体非常清楚地表明，它当然不会引发异常。因此，在这样的示例中，我们只能看到部分管道，因此可以说使情况更加混乱。现在，解析调用者可能会将其放入try-catch块中，期望能够很好地处理异常（如果不要对它太认真地考虑），然后当终端操作抛出该异常时仍会感到惊讶（记住它被sneakyThrow隐藏）。

但是，如果您是从不返回流的人， liftException非常有用。有了它，您的流管道中的一些调用就声明抛出一个检查异常，因此您可以将其全部放入try-catch块中：

try {userStrings.stream().map(liftException(User::parse));.forEach(System.out::println);
} catch (ParseException ex) {// handle exception
}

或者，包含管道的方法可以声明抛出异常：

List<User> parse(List<String> userStrings) throws ParseException {return userStrings.stream().map(liftException(User::parse));.collect(toList());
}

但是正如我之前所说，我认为只有在您永不返回流的情况下，此方法才有效。因为如果这样做（即使只是偶尔这样做），您或您的同事就有可能在重构期间将管道拆开，从而使炸弹处于未声明的检查异常的状态，从而将其隐藏在流中。

Sebastian Millies指出了另一个缺点，即到目前为止使用的接口和方法仅允许一个例外。一旦一种方法声明了多个检查异常，事情就会成问题。要么让Java派生一个公共的超类型（可能是Exception ）， liftException为一个以上的异常声明其他CheckedFunction接口和liftException方法。两者都不是很好的选择。

给定抛出异常的方法，如果需要立即抛出异常，我向您展示了两种不同的方式在流中使用它们：