Connection.close()可能会抛出 ，但我一直认为忽略任何此类异常是安全的（而且我从未见过不忽略它们的代码）。SqlException
通常我会写：
try{
connection.close();
}catch(Exception e) {}
或
try{
connection.close();
}catch(Exception e) {
logger.log(e.getMessage(), e);
}
问题是：
Connection.close()评论：
我知道丢弃异常是邪恶的，但我只拒绝在关闭连接时引发的异常（正如我所看到的，这在这种情况下相当普遍）。
有谁知道什么时候可以扔任何东西？Connection.close()
实际上，你正在做的是（几乎）最佳实践：-）这是我在Spring的JdbcUtils中看到的.java。因此，您可能希望添加另一个 Catch 块。
/**
* Close the given ResultSet and ignore any thrown exception.
* This is useful for typical finally blocks in manual code.
* @param resultSet the ResultSet to close
* @see javax.resource.cci.ResultSet#close()
*/
private void closeResultSet(ResultSet resultSet) {
if (resultSet != null) {
try {
resultSet.close();
}
catch (SQLException ex) {
logger.debug("Could not close ResultSet", ex);
}
catch (Throwable ex) {
// We don't trust the driver: It might throw RuntimeException or Error.
logger.debug("Unexpected exception on closing ResultSet", ex);
}
}
}
总的来说，我曾被人们抛弃这样的例外所浪费了几天。
我建议遵循一些基本规则，但有例外：
如果您绝对确定自己永远不会因已检查的异常而引起问题，请仅捕获该异常并准确注释您不需要处理它的原因。（Sleep抛出了一个中断的异常，除非你真的对它感兴趣，否则它总是可以被忽略，但老实说，这是我通常忽略的唯一情况 - 即使这样，如果你从来没有得到它，那么记录它的成本是多少？
如果您不确定，但您可能偶尔会得到它，请捕获并记录堆栈跟踪，以便在它引起问题时可以找到它。同样，只捕获您需要的异常。
如果看不到可以引发已检查异常的任何方式，请捕获它并将其作为未选中的异常重新引发。
如果您确切地知道导致异常的原因，请捕获它并准确记录原因，那么在这种情况下，如果您非常清楚导致异常的原因，则实际上并不需要堆栈跟踪（如果您尚未使用log4j或其他内容，则可以提及记录异常的类。
听起来你的问题会落入最后一类，对于这种捕获，永远不要做你写的东西（异常e），总是做特定的异常，以防万一一一个未经检查的异常被抛出（坏参数，空指针，...）
更新：这里的主要问题是已检查的异常是不合适的。它们存在的唯一高度使用的语言是Java。它们在理论上是整洁的，但在行动中它们会导致这种捕获和隐藏的行为，而这种行为是未经检查的例外所无法获得的。
很多人评论说，我说过，有时隐藏它们是可以的。具体来说，我能想到的一个案例是：
try {
Thread.sleep(1000);
catch (InterruptedException e) {
// I really don't care if this sleep is interrupted!
}
我想我觉得这种使用是可以的的主要原因是因为这种使用DisruptedException首先是滥用已检查的异常模式，它传达的睡眠结果比指示异常条件更多。
拥有以下功能会更有意义：
boolean interrupted=Thread.sleep(1000);
但是，当他们第一次创建Java时，他们为自己新的检查异常模式感到非常自豪（可以理解的是，它在概念上真的很整洁 - 只是在实践中失败了）
我无法想象这是可以接受的另一种情况，所以也许我应该将其列为忽略异常可能有效的单一情况。
