原文链接：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年写的，但一点也不过时。相比之下我这篇文章有污染搜索引擎之嫌，不管怎样，这算是自我的一个总结，对英文不好的人应该也有些价值。
原文链接：http://www.juvenxu.com/2011/03/30/exception-handling-best-practices/
相关文章
