Java编程中关于异常处理的10个要点
- 如果是可恢复错误,使用检查型异常;如果是编程错误,使用非检查型异常。许多Java编程人员都很苦恼,到底是该选择检查型异常还是非检查型异常。检查型异常是一种从语言到强制你编写代码的一种方式,可以保证你对错误条件提供异常处理代码,但同时也会引入大量杂乱的代码导致其不可读。如果你有恢复策略的话,这样做看起来似乎也可以。
- 在finally程序块中关闭或者释放资源Java程序员对此都有所了解,在处理网络和IO类的时候,相当于一个标准。在finally块中关闭资源, 在正常和异常执行的情况下,保证之前和稀缺资源的合
理释放,这由finally块保证。从Java7开始,该语言有了一项更好的功能:资源管理自动化或者ARM块能实现这一功能。尽管如此,我们仍然要记住在finally块中关闭资源,这是对于释放像FileDescriptors这类,应用在socket和文件编程的情况下的有限资源很重要的。 - 在堆栈跟踪中包含引起异常的原因很多时候,当一个异常由另一个异常导致异常而被抛出的时候,Java库和开放源代码会将一种异常包装成另一种异常。这时,日志记录和打印根异常就变得非常重
要。Java异常类提供了 getCause()方法来检索导致异常的原因,这些可以对异常根层次的原因提供更多的信息。该Java实践对代码的调试或故障排除有很大的帮助。另外,如果你要把一个异常包装成另一种异常,构造一个新异常就要传递源异常。 - 始终提供关于异常的有意义的完整信息异常信息非常重要,因为这是Java程序员最先看到的一个地方,在这里会有非常精确并且真实的信息,他们可以找到问题产生的根本原因。
- 避免过度使用检查型异常 检查型异常在强制执行方面有一定的优势,但同时它也破坏了代码,通过掩盖业务逻辑使代码可读性降低。所以,Java程序员要注意,不能过度使用检查型异常,你可以最大程度的减少这类情况,这样你会得到更精准、简洁的代码。
- 将检查型异常转为运行时异常这个像是Spring之类的多数框架中,用来限制使用检查型异常的技术之一,大部分出自于JDBC的检查型异常,都被包装进 DataAccessException中,而(DataAccessException)异常是一种非检查型异常。特定的异常限制到特定的模块,像
SQLException 放到DAO层,将运行时异常明确的说明然后抛到客户层。 - 记住对性能而言,异常代价比较高异常代价比较高,还会让你的代码运行变得缓慢。如果你有方法从ResultSet(结果集)中进行读取,这时常会抛出SQLException 异常而不会移到下一元素,这将会比不抛出异常的正常代码执行速度慢很多。因此Java程序员要最大限度的减少不必要的异常捕捉和移动。如果你能使用boolean变量去表示执行结果,而不仅仅只是抛出和捕捉异常,你就有可能得到更简洁、更高性能的解决方案。
- 避免catch块为空没有什么会比空的catch块更糟糕的了,因为它不仅隐藏了错误和异常,还可能导致你的对象处于不可使用的状态。空的catch块没有任何意义,如果你非常肯定异常不会继续以任何方式影响对象状态,在程序执行期间,用日志记录错误依然是最好的方法。
- 使用标准异常java程序员应该学会使用标准异常,而不是每次都创建自己的异常。对于维护性和一致性,不管是现在还是以后,都是最好的选择。重用标准异常使代码更具可读性,因为大部分Java开发人员对标准,像源自于JDK的RuntimeException 异常,IllegalStateException 异
常,IllegalArgumentException 异常或者NullPointerException异常,他们能一眼就知道每种异常的目的,而不是在代码里查找或者在文档里查找用户定义的异常的目的。
10.记录任何方法抛出的异常Java提供了throw和throws关键字来抛出异常,在javadoc中用@throw记录任何方法可能会抛出的异常。如果你编写API或者公共接口,这就变得非常重要。任何方法抛出的异常都有相应的文档记录,这样你就能下意识的提醒任何使用(该方法)的人。