57. 只针对异常的情况才使用异常

这个我相信正常人都是这么想的。书上竟然举例用异常来做性能优化,反而把代码可读性弄的更差了。

58. 对可恢复的情况使用受检异常,对编程错误使用运行时异常

59. 避免不必要地使用受检异常

有时候如果受检异常没有提供较好的恢复,还不如不使用反而会对程序更加有帮助

60. 优先使用标准的异常

61. 抛出与抽象想对应的异常

也就是说更高层的实现应该捕获更低层的异常,同时抛出可以按照高层抽象进行解释的异常。

异常链:如果低层的异常对于调试导致高层异常的问题非常有帮助,使用异常链就很合适。

//Exception Chaining
try{
    ...         //use lower-level abstraction to do our bidding
}catch(LowerLevelException cause){
    throw new HigherLevelException(cause);  //关键
}

最佳实践:

  1. 主选方案: 能在低层处理异常则在低层处理异常,实在不行就使用异常转译
  2. 次选方案:低层不能处理异常,则使用日志记录,方便后面来定位问题

62. 每个方法抛出的异常都要有文档

可以用Javadoc的@throw标签记录下一个方法可能抛出的每个未受检异常;

不要使用throws关键字来将未受检的异常包含在方法的声明中

63. 在细节消息中包含能捕获失败的信息

异常的细节信息应该包含所有“对该异常有贡献”的参数和域的值

64. 努力失败保持原子性

失败的时候,操作已经进行了一半,通过编写恢复代码、调整处理过程顺序等方式使得代码能回滚到失败之前的状态。

65. 不要忽略异常