异常处理最佳实战

1. 只在必要使用异常的地方才使用异常，不要用异常去控制程序的流程.。慎地使用异常，异常捕获的代价非常高昂，异常使用过多会严重影响程序的性能。

2. 切忌使用空catch块。千万不要使用空的catch块，空的catch块意味着你在程序中隐藏了错误和异常，并且很可能导致程序出现不可控的执行结果。如果你非常肯定捕获到的异常

不会以任何方式对程序造成影响，最好用Log日志将该异常进行记录，以便日后方便更新和维护。

3. 异常信息放到一个单独的文件中

4. 在finally中释放资源

5. 如果客户端可以从异常中采取行动进行恢复的，就使用checked exception，如果客户什么也做不了，就用unchecked exception。我指的是，不仅仅是记录异常，还要采取措施来恢复。

6. 如果自定义的异常没有提供有用的信息的话，请不要创建它们。尽量使用java定义好的异常类，而非我们自己创建的异常类。它们使我们的代码易读，也避免代码消耗更多内存。

7. 如果你将一个异常包装成另一种异常时，构造一个新异常要传递源异常。

8. 日志中记录详细的异常信息。

9. 记录异常，仅记录一次

异常处理的最佳实践到底是什么？

首先要理解的是，异常到底是什么，我觉得异常分两类。

第一是业务异常，就是处理业务的时候80%的时候是没问题的，但可能有20%的时候事情没有按理想的方向发展。例如注册用户的时候，正常情况是注册成功，但可能用户提交请求的时候，系统发现用户名

已经被别人注册了，这是就可以抛出一个UserAlreadyExistsException。

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

先谈谈业务异常，业务异常应该是接口的一部分，该接口的用户应该能够处理该异常。也就是说，在实现接口之前，就应该定义清楚这个接口会抛出怎样的异常，例如注册用户这个接口就应该明确定义会

抛出UserAlreadyExistsException，并辅以必要文档，那调用者就知道怎么去处理。如果你在接口声明异常，那你一定要确保接口的调用者能够处理之。例如对应于 UserAlreadyExistsException，用户

界面可以提示用户该ID已存在，那用户可以使用另外的ID来注册。注意，处理异常不是简单的catch，然后随便打印点日志那么简单，业务异常的处理应当遵照业务流程。

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

1). 能在底层处理的就本地处理掉，例如网络连接超时异常，可以编写代码尝试再次连接。

2). 能翻译为业务异常的就翻译，有时候你可能发现某个IOException对应有实际的业务意义，但不要直接抛出，而是应该Exception Chaining技术来翻译，

例如 throw new MyOwnException(“sorry, …”, ioe)，这样既不至于丢失原始信息，业务接口也更容易理解。

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

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