注:本文原载于http://www.juvenxu.com/2011/03/30/exception-handling-best-practices/

Exception

作为一个已经写了近5年Java代码的程序员,我直到最近才算是基本明白了异常应该怎么用,这真是令人汗颜。事情是这样的,上周,和往常一样,我在开发一个很平常的应用,并且不得不面对各种各样的异常,比如常见的IOException,或者用到个第三方类库可能会给你返回ThirdPartyException,还有,我自己也会定义异常,姑且叫它MyOwnException。我是使用分层的架构写代码的,比如有个REST层,有个领域模型层,有持久化层,这本没什么问题,可当我发现一个接口要throws三四个或者更多的异常的时候,就觉得蛋疼了,这不仅看起来恶心,如调用者如何处理它们似乎也是个问题。这不是第一次,其实之前蛋疼过很多次了,我一直阅读各种OO设计相关书籍,以理解如何组织各种类和对象,可我还真没仔细考虑过如何组织异常。

好吧,为了以后不再蛋疼,我得弄清楚这个异常的用法。我希望能够明白如何组织异常才能使其变得整洁,而不是肆无忌惮地污染我精心设计的接口。

我翻阅了相关书籍,仔细查看了它们关于异常的描述,包括

  • Implementation Patterns — Kent Beck
  • Clean Code: A Handbook of Agile Software Craftsmanship — Robert C. Martin
  • Effective Java (2ed) — Joshua Bloch
  • Robust Java: Exception Handling, Testing, and Debugging — Stephen Stelting

边阅读边思考,最终基本理解了异常处理的最佳实践。值得一提的是,这几本书中 Joshua Bloch 的描述相比最为全面和深刻,Kent Beck 的最简单粗糙,Robert C. Martin 一书的那一章其实是 Michael Feathers 写的,也只能算是一般,Stephen Stelting 的描述看起来很全面,可太理论了,实例太少,没有说服力。

那异常处理的最佳实践到底是什么?首先要理解的是,异常到底是什么,我觉得异常分两类。

第一是业务异常,就是处理业务的时候80%的时候是没问题的,但可能有20%的时候事情没有按理想的方向发展。例如注册用户的时候,正常情况是注册成功,但可能用户提交请求的时候,系统发现用户名已经被别人注册了,这是就可以抛出一个UserAlreadyExistsException。

第二是系统异常,系统异常与具体业务流程没有直接的关系,例如编程错误导致的NullPointExcpetion,还有坏境问题,例如磁盘损坏或者网络连接不稳定造成了IOException。

先谈谈业务异常,业务异常应该是接口的一部分,该接口的用户应该能够处理该异常。也就是说,在实现接口之前,就应该定义清楚这个接口会抛出怎样的异常,例如注册用户这个接口就应该明确定义会抛出UserAlreadyExistsException,并辅以必要文档,那调用者就知道怎么去处理。如果你在接口声明异常,那你一定要确保接口的调用者能够处理之。例如对应于 UserAlreadyExistsException,用户界面可以提示用户该ID已存在,那用户可以使用另外的ID来注册。注意,处理异常不是简单的catch,然后随便打印点日志那么简单,业务异常的处理应当遵照业务流程。

系统异常由于没有实际业务意义,调用者往往是不知道如何处理的。例如注册用户的时候收到一个IOException,你只会一头雾水。那系统异常应该如何处理呢?有这么几个选择:

  1. 能在底层处理的就本地处理掉,例如网络连接超时异常,可以编写代码尝试再次连接。
  2. 能翻译为业务异常的就翻译,有时候你可能发现某个IOException对应有实际的业务意义,但不要直接抛出,而是应该Exception Chaining技术来翻译,例如 throw new MyOwnException(“sorry, …”, ioe),这样既不至于丢失原始信息,业务接口也更容易理解。
  3. 实在无法处理的,就转换为RuntimeException,反正调用者也不知道怎么处理,那在接口中声明是没有意义的,只会造成调用者困惑并带来负担。这里同样应该使用Exception Chaining以避免信息丢失。我的实际经验告诉我,很多人完全都不考虑使用RuntimeException,这真是莫大的浪费。

有时候业务异常和系统异常的角色会相互转换,例如 FileNotFoundException 对于文件处理这个领域来说是业务异常,可对于我的应用来说,可能只是一个系统异常。

上述是我认为异常处理最核心最有用的实践,除此之外还有不少前人总结的经验,包括:

  • 记录异常,但只记录一次。(不要丢失历史)
  • 不要返回及传Null值。(避免NullPointException和不必要的检查)
  • 尽量重用JDK自带的异常。(以降低学习成本)
  • 在自定义异常中存储异常相关信息字段。(以方便日后处理)
  • 永远不要直接忽略异常。(不要丢失历史)
  • 为异常声明写Javadoc。(对你的用户有好些)
  • 不要 throws 或者 catch 顶层的 Exception 类。(天知道Exception对应什么业务信息)

其实当我读毕前面提到的几本书,然后再Google相关文档的时候,就发现已经有人基本总结过这些内容了:Best Practices for Exception Handling, by Gunjan Doshi, 文章是2003年写的,但一点也不过时。相比之下我这篇文章有污染搜索引擎之嫌,不管怎样,这算是自我的一个总结,对英文不好的人应该也有些价值。