57、只针对异常的情况才使用异常
try {
int i = 0;
while(true)
range[i++].climb();
}catch(ArrayIndexOutOfBoundsException e) {
}
在这段代码中，当循环企图访问数组边界之外的元素时，抛出异常，以达到终止无限循环的目的。在这个代码片段中，基于异常的循环模式不仅模糊了代码的意图，而且降低了性能（异常模式比标准模式慢的多）。
异常应该只用于异常的情况，不要将它们用于控制流，也不要编写迫使客户端使用控制流的API。
58、对可恢复的情况使用受检异常，对编程错误使用运行时异常
Java语言提供了三种可抛出结构（throwable）：「受检的异常」、「运行时异常」和「error」。
-
「受检的异常」是程序可以处理的异常，如果抛出异常的方法本身不能处理它，那么方法的调用者就应该去处理它，从而使程序恢复运行。例如，喷墨打印机在打印文件时，如果纸用完或者墨水用完，就会暂停打印，等待用户添加打印纸或更换墨盒，如果用户添加了打印纸或更换了墨盒，就能继续打印。
-
「运行时异常」是程序无法恢复运行的异常，导致这种异常的原因通常是由于执行了错误操作。一旦出现了错误操作，建议终止程序并仔细的debug，因此Java编译器不检查这种异常。
-
「error」通常是系统出现了不可控的错误，这个错误通常与程序无关，一般不需要处理。 运行时异常和error都是不可恢复的情形。
对于可恢复的情况，使用受检的异常；对于程序错误使用运行时异常。对于自定义的未受检的抛出结构不要继承自Error，它应该是RuntimeException的子类。
59、避免不必要的使用受检的异常
过分使用受检的异常会使API使用起来非常不便，影响API的灵活性。
60、优先使用标准异常
使用标准异常的好处有：使API更易学习和使用、可读性更强和高度的代码重用。
常用的异常：
| 异常 | 使用场合 |
|---|---|
| IllegalArgumentException | 非null的参数值不正确 |
| IllegalStateException | 对于方法调用而言，对象状态不合适 |
| NullPointerException | 参数为null |
| IndexOutOfBoundsException | 下标参数越界 |
| ConcurrentModificationException | 在禁止并发修改的情况下，检测到对象的并发修改 |
| UnsupportedOperationException | 对象不支持用户请求的方法 |
61、抛出与抽象相对应的异常
当方法传递由低层方法抛出的异常时，方法所抛出的异常与它执行的任务没有明显的关系，这往往使人困惑，也让实现细节污染了高层的API。为了避免这个问题，更高层的实现应该捕获低层的异常，同时抛出按高层抽象进行解释的异常。这种做法被称为「异常转译」。
例如：AbstractSequentialList类中
/**
* Returns the element at the specified position in this list.
*
* @throw IndexOutOfBoundsException if the index is out of range
* ({@code index < 0 || index >= size()}).
*/
public E get(int index) {
ListIterator<E> i = listIterator(index);
try {
return i.next();
} catch (NoSuchElementException e) {
throw new IndexOutOfBoundsException("Index: " + index);
}
}
如果低层的异常对于调试导致高层异常的问题有帮助，可以使用「异常链」将低层的异常传到高层的异常中，并使用高层异常的方法（Throwable.getCause）来获取低层异常。如：
try {
...
} catch (LowerLevelException e) {
throw new HigherLevelException(e);
}
总之，如果不能阻止或处理来自低层的异常，一般使用「异常转译」来保证所抛出的异常适合高层。「异常链」：它允许抛出适当的高层异常，同时又能捕获底层的原因进行失败分析。
62、每个方法抛出的异常都要有文档
要为编写的每个方法所能抛出的每个异常建立文档。为每个受检异常提供单独的throws子句，并利用@throws标记记录下抛出每个异常的条件。不要使用throws关键字将未受检的异常包含在方法的声明中。
63、在细节消息中包含能捕获失败的信息
异常的字符串表示法主要是让程序员或域服务人员来分析失败的原因，所以其应该包含尽可能多的失败信息，以便于分析。
为了确保在异常的细节消息中包含足够的能捕获失败的信息，一种做法是在异常的构造器而不是字符串细节消息中引入这些信息。如：
/**
* Constructs an <code>IndexOutOfBoundsException</code> with the
* specified detail message.
* @param lowerBound the lowest legal index value
* @param upperBound the highest index value plus one
* @param index the actual index value
*/
public MyIndexOutOfBoundsException(int lowerBound, int upperBound, int index) {
super("Lower bound: " + lowerBound + ", Upper bound: " + upperBound +
", Index: " + index);
}
//使用
....
throw new MyIndexOutOfBoundsException(0, 10, i);
64、努力使失败保持原子性
一般而言，为了能从异常中恢复，失败的方法调用应该使对象保持在被调用之前的状态，称这中方法具有「失败原子性」。
对于不可变对象，它具有失败原子性是显然的。因为对象的状态始终保持一致。
对于可变对象获得失败原子性最常见的方法：在执行操作之前检查参数的有效性，这可以使对象的状态在被修改之前，先抛出适当的异常。如：
public Object pop() {
if(size == 0)
throw new EmptyStackException();
Object result = elements[--size];
....
}
总之，产生任何异常都应该让对象保持在方法调用之前的状态。若违反了这条规则，API文档中应该清楚的指明对象处于什么样的状态。
65、不要忽略异常
用空的catch块来忽略异常，可能会产生灾难性的后果。永远也不要忽略异常。
网友评论