java - 为什么要将 lambda 中的已检查异常包装在未检查异常中？

Question

我已经成为一名 Java 开发人员大约两年了，如果说我真正喜欢这门语言的一件事那就是流 API。它使我的代码更加流畅、简洁和可读。

令我困扰的一件事是在使用 lambda 时应该如何处理异常。我读过几篇有关该主题的文章，并在 StackOverflow 上看到了几个问题。普遍的共识似乎是您必须包装方法调用以捕获已检查的异常并重新抛出未检查的异常。(像这样:https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams)

但我还没有阅读或理解为什么这是一个好主意。检查异常的优点是调用者知道会发生什么。我被告知，每当您想要执行业务规则时，检查异常(exception)就是最佳选择。应为应用程序无法从异常中恢复的情况保留未经检查的异常。那么为什么他们几乎强制我们在处理流时使用未经检查的异常呢？乍一看这似乎是一个很大的缺陷，对吧？

我目前正在编写一个 SOAP Web 服务，一个很大的优点是所有可能抛出的业务错误都得到了明确的定义。客户端可以对抛出的异常做出相应的响应。抛出运行时异常将导致客户端收到 SOAPFaultException，不知道到底出了什么问题或如何处理它。

我可以使用全局异常处理程序并捕获所有可能的 RTE(假设我不会忘记一些 RTE)，然后再次将它们作为 XSD/WSDL 中定义的已检查异常之一重新抛出。但我很难说服我的高级同事相信函数式编程的好处，并告诉他们将检查的异常包装在未检查的异常中，只是将它们转回检查的异常绝对不会帮助我摆脱困境。

那么为什么在 lambda 中捕获已检查的异常并将它们包装在未检查的异常中被认为是最好的方法呢？很少有其他场景我们会真正捕获已检查的异常并抛出未检查的异常。那么为什么它被认为是使用 lambda 时的最佳选择呢？真的是因为考虑到语言的限制，这是唯一可能的方法(对于 Lombok 的 @SneakyThrows 等一些肮脏的解决方法来说是安全的)？那么你如何应对所有这些非制导导弹呢？

Answer 1

Why should you wrap checked exceptions in lambda's in an unchecked exception?

简短回答:因为你必须这样做。 (差不多了。)

So why did they pretty much force us to use unchecked exceptions when working with streams? This seems like a big flaw at first glance, right?

无需深入历史和关于检查异常是否是错误的争论......

流和 lambda 中的异常处理实际上是 Java 异常和异常处理的一般设计的直接结果。后者无法改变:这对于 Oracle 现有的 Java 客户群来说破坏性太大。因此，在可预见的 future ，我们将陷入困境。

Is it really because it is the only possible way to do so (safe for a few dirty workarounds like Lombok's @SneakyThrows) given the language's limitations?

是的，这是唯一的方法。这是否是一个好方法。

And then how are you to handle all these unguided missiles?

一种方法是简单地让未经检查的(或偷偷检查的)异常传播。在大多数情况下，应用程序或线程会崩溃，您可以使用日志文件中的堆栈跟踪来查找/修复根本原因。这假设原始检查异常不是“预期的”，因此不能真正恢复。

如果您尝试使应用程序从检查的异常中恢复:

• 对于包装的异常，您可以捕获 RuntimeException，然后使用 ex.getClass() 和 ex.getCause() 来决定要做什么。

• 对于偷偷摸摸的检查异常，您可以捕获 Exception 并使用 instanceof 来区分(预期的)偷偷摸摸的检查异常和未检查异常。