为什么 Kotlin Result 会捕获 Throwables？

Question

在 Java 中，捕获和处理 Throwables 被认为是一种不好的做法，因为它们包含不可恢复的错误。但是，来自 Kotlin 标准库的 runCatching 和 mapCatching 确实像任何其他异常一样捕获它们并将它们包装在 Result 中。在 Kotlin 中捕获 Throwables 通常是可以的，还是 Result 是一个特例（如果是，为什么）？

Answer 1

我发现了Kotlin 语言研究团队负责人 Roman Elizarov 发布的一系列关于该主题的推文：

如果您需要错误记录/处理（通常在顶层），请 catch Throwable。[...]事实上catch(e: Exception)[是一种不好的做法]。您要么捕获需要处理的特定于操作的异常（例如 IOException），要么捕获所有异常（这意味着Throwable）。我从来没有在你的代码中看到过真正的理由catch(e: Exception)。这是一个等待攻击你的错误。

关于不可恢复错误和可恢复异常之间的区别：

Java 在 1996 年就想做出这种区分，但随着平台的发展和扩展，它未能坚持下去。事实上，现在在实践中永远不可能判断问题是否可以通过其类来恢复。JVM 的区别和整个命名混乱只是过去时代 25 年前的遗产。当时没有人能够真正预测到这一切在大系统中是如何运作的。

关于如何处理错误：

记录它、通知支持人员、重新启动受影响的操作/子系统等。没有理由将这些操作仅限于Exception子类型。我几乎从未遇到过日志记录或以其他方式处理 OutOfMemoryError、StackOverflowError、AssertionError和其他问题（除了 JVM 中罕见的致命错误）。事实上，它们在代码中得到了正确的处理，从而节省了后来无数个小时的支持工作。在实践中，OOM 通常是由尝试分配一些非常大的数据结构的代码中的错误引起的。当此代码因 OOM 崩溃时，GC 会清理内存，这至少可以让您的错误处理代码正确记录它。