38、只针对不正常的条件使用异常
异常只应该被用于不正常的条件，它们永远不应该被用于不正常的条件
设计API启示：一个良好的API不应该强迫它的客户为了正常的控制流而使用异常。对于边界的判断常用的有两种方法：状态测试方法和可被识别的返回值

40、对于可以恢复的条件使用被检查的异常，对于程序错误使用运行时异常
 Thowable（可抛出异常）有三种结构：被检查的异常(checked exception)、运行时异常（run-time exception)和错误(error)
如果期望调用者能够恢复，那么，对于这样的条件应该使用被检查的异常
运行时异常和错误，不需要也不应该是被捕获的抛出物
用运行时异常来指明程序错误
对于被检查的异常，提供一些辅助方法是非常重要的，通过这些方法，调用者可以获得一些有助于恢复的信息

41、避免不必要地使用被检查的异常

42、尽量使用标准异常
      

43、抛出的异常要适合于相应的抽象
高层的实现应该捕获低层的异常，同时导出一个可以按照高层抽象进行解释的---异常转译
低层的异常对于调试该异常被拨出的情形非常有帮助的话，可以使用异常链接。即低层的异常被高层的异常保存起来，并且高层的异常提供一个公有的访问方法来获得低层异常

44、每个异常的抛出都必须有文档

45、在细节消息中包含失败--捕获信息
为了捕获失败，一个异常的的字符串表示应该包含所有“对异常有贡献”的参数和域的值
在异常构造函数中以参数形式引入这些信息

46、努力使失败保持原子性
一个失败方法调用应该使用对象保持“它在被调用之前的状态” ---failure atomic
几种解决方法：在执行操作之前检查参数的有效性
调整计算机过程，使得任何可能会失败的计算部分发生在对象状态被修改之前
编写一段恢复代码
在对象上临时都拷贝一份，当操作完成之后把临时拷贝中的结果复制给原来的对象。如：Collections.sort

47、不要忽略异常
写上try catch块