java - 为什么 Java 既有检查异常也有未检查异常？

Question

<分区>

Answer 1

检查异常的理论很简单。

在设计接口(interface)时，请考虑在方法调用的正常状态下可能发生并且将会发生的异常情况。在您的接口(interface)中声明这些异常，因为程序员必须直接处理它们。

例如，银行账户提款方法可能会声明一个 OverdraftException，这是一个预期的异常 - 提款可能会因 overdraw 而失败，但这种类型的失败可能会被客户端代码以不同的方式处理(可能会决定完全拒绝取款，另一个人可能会决定应用巨额罚款并允许记录负余额，另一个人可能会决定允许他们的客户从不同的账户提款。

但是，运行时异常应该是不应直接处理的编程错误 - 例如 NullPointerExceptions，只有在方法采用无效参数或不直接检查此类情况时才会发生。

这是一个很好的理论。然而，Java 搞砸了异常的实现，这使该理论的书被抛到了窗外。

我将通过两个案例来说明 Java 在其异常实现方面搞砸的地方。它们是 IOException 和 SQLException。

IOException 随时随地发生，Java 的 IO 库中的流发生困惑。但是，这是一个已检查的异常。但是，通常您只能记录发生的错误 - 如果您只是向控制台写入数据，那么如果您在写入时突然收到 IOException 异常，您应该怎么办？

但还有更多。

IOException 还隐藏了文件异常和网络异常等内容。它们可能是为此 float 的 IOException 的子类，但它仍然是一个已检查的异常。如果您写入外部文件失败，您实际上无能为力 - 如果您的网络连接被切断，同上。

SQLException同理。异常名称应显示调用它们时发生的情况。 SQLException 没有。在处理数据库时遇到任何可能数量的错误时，都会抛出 SQLException - 大多数错误与 SQL 无关。

因此，程序员通常对处理异常感到恼火，并让 Eclipse(或他们使用的任何 IDE)生成这样的 block :

try {
thisMethodThrowsACheckedExceptionButIDontCare();
}
catch(Exception e) {
e.printStackTrace();
}

但是，对于 RuntimeExceptions，这些有意冒泡并最终由 JVM 或容器级别处理。这是一件好事 - 它强制显示错误，然后你必须直接修复代码而不是忽略异常 - 你可能仍然最终只是打印堆栈跟踪(希望记录它而不是直接打印到控制台)，但是那么就会有一个异常处理程序，你是因为一个真正的问题而被迫编写的——不是因为一个方法说它可能可能会抛出一个异常，而是它确实抛出了异常。

Spring 使用 DataAccessException 来包装 SQLException，这样您就不必将它们作为已检查的异常来处理。结果它使代码更清晰——如果你期望一个 DataAccessException，你可以处理它——但大多数时候你让它传播并记录为错误，因为你的 SQL 应该在你发布应用程序时调试，这意味着 DataAccessException 可能是您无法解决的硬件问题 - DataAccessException 是一个比 SQLException 更有意义的名称，因为它表明数据访问失败 - 而不是您的 SQL 查询必然有错误。