57. 只针对异常的情况才使用异常
这个我相信正常人都是这么想的。书上竟然举例用异常来做性能优化，反而把代码可读性弄的更差了。
58. 对可恢复的情况使用受检异常，对编程错误使用运行时异常
59. 避免不必要地使用受检异常
有时候如果受检异常没有提供较好的恢复，还不如不使用反而会对程序更加有帮助
60. 优先使用标准的异常
61. 抛出与抽象想对应的异常
也就是说更高层的实现应该捕获更低层的异常，同时抛出可以按照高层抽象进行解释的异常。
异常链：如果低层的异常对于调试导致高层异常的问题非常有帮助，使用异常链就很合适。
//Exception Chaining
try{
... //use lower-level abstraction to do our bidding
}catch(LowerLevelException cause){
throw new HigherLevelException(cause); //关键
}
最佳实践：
- 主选方案： 能在低层处理异常则在低层处理异常，实在不行就使用异常转译
- 次选方案：低层不能处理异常，则使用日志记录，方便后面来定位问题
62. 每个方法抛出的异常都要有文档
可以用Javadoc的@throw标签记录下一个方法可能抛出的每个未受检异常；
不要使用throws关键字来将未受检的异常包含在方法的声明中
63. 在细节消息中包含能捕获失败的信息
异常的细节信息应该包含所有“对该异常有贡献”的参数和域的值
64. 努力失败保持原子性
失败的时候，操作已经进行了一半，通过编写恢复代码、调整处理过程顺序等方式使得代码能回滚到失败之前的状态。