有没有人能想到一个合理的理由，解释为什么SQLException是一个已检查的异常？
是的，可能会出现查询语法错误
是的，连接可能断开了
是的，可能存在权限问题
等等，等等，诸如此类的问题
但实际上，在生产环境下，近乎100%的时间（一旦您开始运行），都不会出现任何问题。
如果出现问题，调用代码无法执行任何恢复操作，因此应将其设置为未检查的。
由于SQL的深奥性质，异常的多种原因和复杂性意味着您基本上无法进行恢复，除非异常是由于暂时的网络问题引起的，但即使在同步调用中，您也将失败，因为您不能无限期地等待网络问题得到解决，所以您必须失败事务。
通常，调用SQL看起来像这样：
try {
// make some SQL call(s)
} catch {SQLException e) {
// log the exception
return; // and give up
}
这样的代码没有任何价值。你无法采取任何合理的措施来恢复。与其如此，不如让运行时异常冒泡——即SQLException应该是一个运行时(未检查的)异常。
实际上，几乎100%的时间都没有问题 - 这仅限于你自己的观察，并不代表其他系统。世界各地有各种计算机系统，存在各种瓶颈。您的成功率几乎达到了100％。其他人必须处理低得多的百分比。
常见误解是根据其出现的频率来考虑引入/删除Checked Exception。Checked Exceptions作为通信渠道。正如您所知，每个方法都有其公共接口。这样，方法告诉我们它接受哪些参数以及其主体代码的结果。
当正在进行的方法无法实现其承诺（例如返回值）时，它需要一种方法告诉其他方法出了问题，它无法完成预期的任务。但是该怎么做？将消息作为返回的值发送不起作用，调用方法几乎无法区分正确值和错误消息。更不要说一些方法将void作为返回值。那么当您无法遵守由您的方法接口定义的承诺时该怎么办？好吧，您抛出异常（发送消息）。
如果您期望ResultSet并且未建立与数据库的连接，应该怎么办？返回空ResultSet吗？当然不，这告诉我们数据库是空的。返回null？这只会委托问题并使查找原因变得不清楚。
您可以使用该空结果集，并将其作为另一个查询的一部分用于另一个数据库，从而使其不一致。
没有SQLException，即使出现一个错误也可能导致数据不一致。
SQLException是一个已检查的异常。SQLException而言，我认为只有这个类才知道：
try { ... }
catch(SQLException e)
{
SomeLogger.log(...);
rollback();
throw e;
}
catch Exception，它会捕获未经检查的异常，就像它捕获NPE一样；只是因为异常未经检查并不意味着您的“应用程序将崩溃”。如果您想要的话，仍然可以捕获特定的未经检查的异常。 - BohemianSQLException实际上就是一个Error：你基本上无法从中恢复 - 你的应用程序已经崩溃了 - 而且Errors是不受检查的。为什么SQLException也不是呢。 - Bohemian