第57条： 只针对异常情况才使用异常
异常是为了在异常情况下使用而设计的，不要将它们用于普通的控制流，也不要编写迫使它们这么做的API。
第58条： 对可恢复的情况使用受检异常，对编程错误使用运行时异常
所有的异常、错误都继承自Throwable，它直接包含了两个子类Error和Exception。
Error用来表示编译时和系统错误，Exception是可以被抛出的基本类型，通常情况下我们只关心Exception异常，而Error错误是程序员控制不了的系统错误。
对于Exception异常又分为两种：受检查的异常和不受检查的异常，受检查的异常直接继承自Exception，不受检查的异常则继承自RuntimeException（RuntimeException也继承自Exception)。
受检查的异常在编码中就是需要被try-catch捕获或者通过throws抛出的异常，例如在进行I/O操作时候常常都会明确要求对文件的操作需要对异常进行处理。
而对于不受检查的异常就是不需要在代码中体现但也可以对这种异常出现时做处理，例如经常遇到的就是空指针异常（NullPointerException）。因为不受检查的异常全部继承自RuntimeException，此条目中所说的“运行时异常”也就是不受检查的异常。
什么时候使用受检查的异常（throws Exception），什么时候使用不受检查的异常（throws RuntimeException），本书中给出原则是：如果期望调用者能够适当地恢复，对于这种情况就应该使用受检的异常。对于程序错误，则使用运行时异常。例如在数据库的事务上通常就会对异常做处理，防止出现数据不一致等情况的发生。
第59条： 避免不必要地使用受检异常
关于这条建议书中实际上是建议如何更好的“设计”异常处理。
对于异常本身初衷是使程序具有更高的可靠性，特别是受检查的异常。但滥用受检查的异常可能就会使得程序变得负责，给程序员带来负担。
两种情况同时成立的情况下就可以使用受检查的异常：1、正确地使用API并不能阻止这种异常条件的产生；2、如果一旦产生异常，使用API的程序员可以立即采取有用的动作。以上两种情况成立时，就可以使用受检查的异常，否则可能就是徒增烦恼。
另外在一个方法抛出受检查异常时，也需要仔细考量，因为对于调用者来讲就必须处理做相应处理，或捕获或继续向上抛出。如果是一个方法只抛出一个异常那么实际上可以将抛出异常的方法重构为boolean返回值来代替。
第60条： 优先使用标准的异常
对异常的时候都知道可以自定义异常，但往往在尚不标准的开发工程中都是不管三七二十一统统捕获或者抛出Exception异常。实际上更好的是使用内置的标准的异常而不是这么笼统。例如参数值不合法就抛出llegalArgumentException等。
第61条： 抛出与抽象相对应的异常
当低层抛出异常时，此时要考虑是否做异常转译，使得上层方法的调用者易于理解。
第62条： 每个方法抛出的异常都应该要有文档
为抛出的异常建立Java的文档注释即Javadoc的@throws标签。对于一些未受检的异常同样也应该在文档注释中说明。
第63条：在细节消息中包含能捕获失败的信息
关于此条目的建议可以归结于如何编写好的日志。在刚工作的时候关于日志的打印对我来说基本是不知道怎么来写的，不知道在哪里写，不知道怎么写，需要包含什么内容。对于异常的捕获，在平时只在IDE中的控制显示并且没有日志记录他通常都会这么写：e.printStackTrace();
在生产环境中当然不能这么写而需要打印到日志中，除了堆栈信息外还需要一个可跟踪的信息，这通常是一个用户的ID，总之就是需要可定位、可分析。
第64条：努力使失败保持原子性
失败的方法调用应该使对象保持在被调用之前的状态，具有这种属性的方法被称为具有失败原子性。
失败过后，我们不希望这个对象不可用。在数据库事务操作中抛出异常时通常都会在异常做回滚或者恢复处理，要实现对象在抛出异常过后照样能处在一种定义良好的可用状态之中，有以下两个办法：
1） 设计一个不可变的对象。不可变的对象被创建之后它就处于一致的状态之中，以后也不会发生变化。
2） 在执行操作之前检查参数的有效性。例如对栈进行出栈操作时提前检查栈中的是否还有元素。
3） 在失败过后编写一段恢复代码，使对象回滚到操作开始前的状态。
在对象的一份临时拷贝上执行操作，操作完成过后再用临时拷贝中的结果代替对象的内容，如果操作失败也并不影响原来的对象。
第65条：不要忽略异常
try { doSomething(); } catch (Exception e) { }
强烈不建议这样写，如果一定要这么写，就需要加以注释。