这可能不适合 SO，因为它不是真正的编码问题，但我还找不到令人满意的答案，我相信 SO 社区可以。
因此，根据定义，android.database.SQLException和java.sql.SQLException共享相同的应用范围，即在访问/修改数据库时提供有关错误的信息。尽管我在某处读到过检查异常已“退出”，但我真的很喜欢这样一个事实，即当您使用throws关键字检查异常时，编译器会提醒您处理异常。不幸的是，这不适用于未经检查的异常。
我的问题是：为什么谷歌在android.database.SQLException检查时java.sql.SQLException不检查？我错过了什么吗？它们的差异比我想象的要大吗？
在检查或未检查异常之间进行选择总是有点主观：
如果异常表示错误或某些“可能无法恢复”的故障，那么未经检查的异常是合适的。
如果异常指示“可能可恢复”的故障，则检查异常是合适的。
在这种情况下，有很多子类的一般例外情况会更加困难。其中一些子类可能是错误，也可能是可恢复的。此时，设计人员必须对不同情况的相对可能性做出价值判断……跨越所有已知/预测的异常子类型。
在这种情况下，Sun 和 Google 的工程师得出了不同的结论。但请注意，Google 工程师拥有 Sun 工程师所没有的巨大优势。他们可以查看 Java 设计，并自行判断它与已检查的SQLException.
尽管我在某处读过检查的异常已“出局”...
有很多开发人员希望所有 Java 异常都未检查，这样他们就不必被迫处理它们。还有很多其他开发人员仍然认为 Java 在检查异常方面是正确的……即使在少数情况下做出了错误的选择（事后看来）。
这是值得商榷的。
我错过了什么吗？它们的差异比我想象的要大吗？
并不真地。这两个异常层次结构的用途几乎相同……尽管 javadoc 类描述存在差异。
android.database.SQLException是基于java.lang.RuntimeException并且不需要检查，但java.sql.SQLException不是。
在Unchecked Exceptions — The Controversy有一个简单的解释。
我认为在许多情况下，未经检查的异常比检查的异常更喜欢。原因是您不会被迫以任何方式抓住它。如果你认为有必要，你可以在你的代码中加上一个try-catch子句，但你不是必须的。这有效地使您的代码更好，因为程序员可以决定要做什么。
在您的示例中，没有特别的原因为什么必须成功checked或不成功。这是一个设计问题，我认为谷歌在android.database.SQLException.
我认为是这样的原因是：
android.database.SQLException ：表示 SQL 解析或执行出错的异常。
和
java.sql.SQLException ：提供有关数据库访问错误或其他错误的信息的异常。
因此，很明显这android.database.SQLException很可能是RuntimeException因为它发生在 SQL 解析或执行出错时。而，java.sql.SQLException是由于数据库访问错误或其他此类错误导致的异常，因此足以将其保留为已检查异常。每当您使用开放连接或任何类似的东西时，最好将它们放在检查异常的保护伞下。