转载：异常处理最佳实践

本文系全文转载，原文链接地址是：http://www.juvenxu.com/2011/03/30/exception-handling-best-practices/。只有最后一段是我的补充

作为一个已经写了近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，你只会一头雾水。那系统异常应该如何处理呢？有这么几个选择：

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

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

记录异常，但只记录一次。（不要丢失历史）
不要返回及传Null值。（避免NullPointException和不必要的检查）
尽量重用JDK自带的异常。（以降低学习成本）
在自定义异常中存储异常相关信息字段。（以方便日后处理）
永远不要直接忽略异常。（不要丢失历史）
为异常声明写Javadoc。（对你的用户有好些）
不要 throws 或者 catch 顶层的 Exception 类。（天知道Exception对应什么业务信息）
其实当我读毕前面提到的几本书，然后再Google相关文档的时候，就发现已经有人基本总结过这些内容了：Best Practices for Exception Handling, by Gunjan Doshi， 文章是2003年写的，但一点也不过时。相比之下我这篇文章有污染搜索引擎之嫌，不管怎样，这算是自我的一个总结，对英文不好的人应该也有些价值。

————————————————正文结束————————————————

原文写得很好，稍微长了点，我总结补充如下：

1、作者认为异常分为“业务异常”和“系统异常”，正好java也有CheckedException和UncheckedException之分，我感觉可以对应起来。

对于“业务异常”，上层类应该知道是如何处理的，所以将“业务异常”声明为CheckedException，作为接口的一部分，强制要求上层捕获处理，这是合理的

对于“系统异常”，上层类就算catch住了，也是无能为力，所以将其声明为CheckedException，意义是很小的，往往也只能继续向上抛出，或者记录日志就消化掉。反而会有不必要的try catch，影响代码的可读性。所以对于这类异常，可以声明为UncheckedException，不强制上层捕获处理

2、对于业务层无法处理的异常，不可避免地会抛到展现层。那么这个时候，至少要做两件事情，一个是记录日志，另一个是页面跳转，不让用户直接看到500。如果展现层用的是struts2框架的话，可以通过global-exception-handler来实现

3、如果用spring管理事务，那么业务层是不能把DAO层的异常消化掉的，否则的话spring管理的事务就无法生效了，在一个系统中考虑异常处理机制的时候，务必考虑这一点

4、对于MyOwnException，作者建议采用Exception Chaining来实现