Java异常处理之最佳实践

引言：

- 编程错误导致的异常：譬如NullPointerException和IllegalArgumentException），代码通常对编程错误没有什么对策。
- 客户端的错误导致的异常：试图违背制定的规则，例如读写文件流的关闭操作。
- 资源错误导致的异常：当获取资源错误时引发的异常。例如，系统内存不足，或者网络连接失败。

对于Java作为第一个使用checked exception的主流面向对象语言而言，高层必须catch或throw，若不能有效的处理异常的话，就会在API和代码之间造成负担。

Checked exception被诟病破坏封装性：getAllAccounts使得调用者必须处理这两个异常，但调用者不知道什么文件找不到&什么数据库语句失败，也不知道该提供什么文件系统或者数据库的事物层逻辑。这使得方法与调用者之间形成不恰当的紧耦合关系。

设计API的最佳实践

1. 根据客户端如何应对Exception决定使用checked exception还是unchecked exception
分析：若客户端可以采取行动恢复的建议采用checked exception
unchecked exception建议多用，因为它不强迫客户端必须处理，会扩散直到客户端想处理。建议采用Java定义好的异常类，更有利于代码的易读性。

2. 保持封装性
不要将针对某特定实现的checked exception用到更高的层次中去。

例如不要让SQLException扩散到逻辑层去，因为逻辑层是不需要知道SQLException。解决办法：a.客户端有相应应对措施时，转换SQLException为另一个checked exception

b.若客户端无法处理，转换SQLException为unchecked exception4. 将异常文档化你可以采用Javadoc’s @throws标签将你的API抛出的checked和unchecked
exception都文档化。

3. 不要忽略异常当一个API方法抛出checked exception时，如果对你没什么意义，直接转换成unchecked exception抛出，而不要仅仅用空的catch来忽略该异常。

处理示例：
之前代码：

4. 如果自定义的异常没有提供有用的信息的话，请不要创建它们。

a.当前异常发生时，给出一些相关的数据信息

b.若不想获取详细信息，抛出标准异常也可以。

使用异常的最佳实践

1. 记得释放资源

2. 不要使用异常作控制流程之用

生成栈回溯的代价很昂贵，栈回溯的价值是在于调试，而不是流程控制中。

3 不要catch最高层次的exception

4.尽量减小try代码块

来自为知笔记(Wiz)