为什么android.database.SQLException未经检查？

Question

这可能不适合SO，因为它不是真正的编码问题，但我找不到令人满意的答案，我相信SO社区可以。

因此，根据定义，android.database.SQLException和java.sql.SQLException共享相同的应用程序范围，即在访问/修改数据库时提供有关错误的信息。虽然我已经读过某些检查异常是“out”的地方，但我真的很喜欢当你使用带有throws关键字的已检查异常时编译器提醒你处理异常的事实。不幸的是，这不适用于未经检查的异常。

我的问题是： 为什么Google在android.database.SQLException被选中时未选中java.sql.SQLException？我错过了什么吗？他们的差异是否超出我的想象？

Answer 1

选中或取消选中例外之间的选择总是有点主观：

• 如果异常表示存在错误，或某些“可能无法恢复”的错误，则应采用未经检查的异常。

• 如果异常表明“可能是可恢复的”失败，那么检查的异常是合适的。

在这种情况下，如果存在许多子类的一般异常，则会更加困难。其中一些子类可能是错误，或者可以可恢复。此时，设计者必须对异常的所有已知/预测子类型的不同情况的相对可能性做出价值判断。

在这种情况下，Sun和Google工程师得出了不同的结论。但请注意，Google工程师具有Sun工程师所没有的巨大优势。他们可以查看Java设计，并使用已检查的SQLException自行判断它的工作情况。

---

  

虽然我已经在某个地方看过，检查异常是“出去”......

有很多开发人员希望不检查所有Java异常，这样他们就不必被迫处理它们。还有很多其他的开发人员仍然认为Java使用经过检查的异常才能做到正确...即使有少数情况下做出了错误的选择（事后看来）。

这是值得商榷的。

  

我错过了什么吗？他们的差异是否超出我的想象？

不是真的。这两个异常层次结构的用途几乎相同......尽管javadoc类描述存在差异。

Answer 2

android.database.SQLException基于java.lang.RuntimeException，无需检查，但java.sql.SQLException不是。

在Unchecked Exceptions — The Controversy，有一个简单的解释。

Answer 3

我认为在许多情况下，未经检查的异常更喜欢检查异常。原因是你不是强制以任何方式捕获它。如果您认为有必要，可以使用try-catch子句包围您的代码，但您不必这样做。这有效地使您的代码更好，因为程序员可以决定做什么。

在您的示例中，没有特别的原因为什么必须将其设为checked。这是一个设计问题，我认为Google使用android.database.SQLException做得更好。

Answer 4

我认为是这样的原因是因为：

  

android.database.SQLException：一个异常，指示SQL解析或执行时出错。

和

  

java.sql.SQLException：提供有关数据库访问错误或其他错误的信息的异常。

因此，android.database.SQLException很可能是RuntimeException，因为它在SQL解析或执行时出错。 然而，java.sql.SQLException是由于数据库访问错误或其他此类错误导致的异常，因此它足以将其保留为已检查的异常。无论何时使用开放式连接或任何此类事物，最好将它们置于已检查异常的保护之下。