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); } } }
总的来说,我已经浪费了几天人们抛弃这样的例外情况.
我建议遵循以下几条基本规则:
如果你绝对确定你将永远不会导致检查异常的问题,抓住JUST该异常并准确评论为什么你不需要处理它.(Sleep会抛出一个InterruptedException,除非你真的对它感兴趣,否则总是可以忽略它,但说实话,这是我经常忽略的唯一情况 - 即使在那种情况下,如果你从来没有得到它,记录它的成本是多少?)
如果您不确定,但偶尔可以得到它,请捕获并记录堆栈跟踪,以便如果它导致问题,则可以找到它.再次,只捕获您需要的异常.
如果您没有看到任何方法可以抛出已检查的异常,请捕获它并将其作为未经检查的异常重新抛出.
如果你确切地知道导致异常的原因,抓住它并准确记录原因,在这种情况下你真的不需要堆栈跟踪如果你非常清楚是什么导致了它(你可能会提到正在记录它的类如果你还没有使用log4j或其他东西.
听起来你的问题会落到最后一个类别,对于这种类型的捕获,永远不会做你写的(异常e),总是做一些特定的异常以防万一抛出一些未经检查的异常(坏参数,空指针, ...)
更新:这里的主要问题是Checked Exceptions是不合适的.他们存在的唯一高度使用的语言是Java.它们在理论上是整洁的,但是在行动中它们会导致捕捉和隐藏的这种行为,而你没有得到未经检查的异常.
很多人评论说我有时候隐藏它们是好的.具体来说,我能想到的一个案例是:
try { Thread.sleep(1000); catch (InterruptedException e) { // I really don't care if this sleep is interrupted! }
我认为我觉得这种用法的主要原因是好的,因为这种InterruptedException的使用首先是滥用已检查的异常模式,它正在传达睡眠的结果而不是指示异常情况.
拥有以下内容会更有意义:
boolean interrupted=Thread.sleep(1000);
但是当他们第一次创建Java时,他们为他们新的检查异常模式感到非常自豪(可以理解的是,它在概念上非常简洁 - 只在实践中失败)
我无法想象另一种情况下,这是可以接受的,所以也许我应该列出这是对单一情况下它可能是有效的忽视一个例外.
在最起码,总是 永远 永远记录你正在迎头赶上,而不是作用于异常.
在没有最微小的窥视的情况下,悄悄地捕获的异常是最糟糕的.