exception - Kotlin 删除检查异常背后的想法是什么？

Question

当我们在 Java 中调用抛出异常的方法时，我们该如何处理呢？

我的代码在 kotlin 中，我使用的是用 java 编写的第 3 方库。我调用了这个库的一个方法，它在某些情况下会抛出很少的自定义异常。现在 kotlin 并没有强制我处理这个异常，在这种情况下应用程序会崩溃。处理此问题的最佳方法是什么？

Answer 1

当 Java 引入检查异常时——编译器强制大多数异常要么被捕获，要么被声明为抛出——这是一个相当新的想法。 Java 是一种比大多数前辈更安全的语言:所有行为在所有平台上定义和一致，许多功能旨在防止崩溃、意外行为或脆弱的编码。所以检查异常非常符合语言的哲学。
但从那以后的几年里，许多人得出结论，检查异常是一个错误。我并不完全相信，但这里有一些原因:

他们很冗长。 包含许多 try 的方法很常见。 … catch block ，和/或声明许多异常。另外，如果在抛出异常和捕获异常之间有 6 个级别的方法调用，则需要通过 5 个方法声明异常。
Kotlin 取消了 Java 的大部分样板文件，并且取消了检查的异常符合这一点。

他们鼓励不良做法 :

试图在错误的地方处理异常，即在错误的抽象级别，没有什么有用的事情可以做。

无意义catch block (尤其是那些除了记录错误什么都不做的危险 block )。

捕获/申报Exception而不是特定的子类型。

通过将检查的异常包装在未经检查的异常中来作弊，例如 RuntimeException .

它们增加了模块之间的耦合。 如果您正在使用添加新异常的库方法，则需要更新调用该方法的所有代码以处理或重新抛出它。

他们需要翻译异常(exception) 不同抽象层次之间。 (例如，数据库访问层可能必须将套接字超时异常转换为数据库不可用异常。)这很乏味，但有必要避免暴露实现细节。

它们不适用于继承。 如果您正在实现/覆盖的方法未声明为抛出特定的检查异常，那么您的实现也不能抛出它。

它们不适用于 lambda。 在 Java 中，lambda 是使用 Single-Abstract-Method 接口(interface)实现的，因此这些方法必须声明可能的异常(在这种情况下，每个用法都必须处理或声明它)，或者 lambda 主体必须捕获异常。这两个选项都大大增加了概念权重以及使用 lambdas 所需的代码，破坏了简洁性，这是它们的主要优点之一。
Kotlin 的实现非常相似(尽管它使用自己的 KFunction 接口(interface))，并且会遇到同样的问题。

对于所有这些问题，很明显，检查异常充其量只是喜忧参半。我可以理解为什么 Kotlin 已经取消了它们。
我确实担心它可能会导致程序不那么健壮(并且文档记录较少)。但是在我使用 Kotlin 的两年中，我还没有看到任何明显的案例。所以我现在暂缓判断:-)
(另见 this 问题。)

至于如何处理您的特殊情况，我建议您像 Kotlin 已检查异常时所做的那样:查看您调用的方法可以抛出哪些异常，找出处理它们的最佳方式/最佳位置，并处理他们!仅仅因为 Kotlin 没有强制你这样做，并不意味着它仍然不是一个好主意!