异常机制可以使程序中异常处理代码和正常业务代码分离，提高程序的可读性、可靠性和可维护性。
1.只针对异常的情况才使用异常
异常机制的设计初衷是用于不正常的情形，它只能用于异常的情况，永远不应该用于正常的控制流。
设计良好的API不应该强迫它的客户端为了正常的控制流而使用异常。如果类具有“状态相关”的方法，这个类往往也应该有个单独的“状态测试”方法，指示是否可以调用这个状态相关的方法。例如，Iterator接口有一个“状态相关”的next()和相应的状态测试方法hasNext()。这使得利用for循环对集合进行迭代的标准模式成为可能：
for (Iterator<Foo> i = collection.iterator(); i.hasNext(); ) {
Foo foo = i.next();
...
}
如果Iterator缺少hasNext()，客户端将被迫改用下面的做法：
try {
Iterator<Foo> i = collection.iterator();
while(true) {
Foo foo = i.next();
...
}
} catch (NoSuchElementException e) {
}
异常是为了在异常情况下使用而设计的，不要将它们用于普通的控制流，也不要编写迫使它们这么做的API。
2.对可恢复的情况使用受检异常，对编程错误使用运行时异常
JDK异常体系结构如下图所示（只列出部分常见异常）：
Java语言提供了三种可抛出结构（throwable）：
- 受检的异常（checked exception)
- 运行时异常（run-time exception）
- 错误（error）
异常的使用情形：
- 期望能从异常恢复时，应该使用受检异常
- 用运行时异常来表明编程错误
运行时异常和错误都是未受检的可抛出结构，在行为上两者是等同的，它们都不需要也不应该被捕获。如果程序抛出未受检的异常或错误，往往就属于不可恢复的情形，继续执行下去有害无益，此时系统应做的就是及时终止，并及时提示错误信息。
按照惯例，错误往往被JVM保留用于表示资源不足、约束失败，或者其他使程序无法继续执行的条件。因此最好不要再实现任何新的Error子类。实现的所有未受检的抛出结构都应该是RuntimeException直接或间接的子类。
对于可恢复的情况，使用受检异常；
对于程序错误，使用运行时异常。
异常也是个完全意义上的对象，可以在它上面定义任意的方法。这些方法的主要用途是为捕获异常的代码提供额外的信息，特别是关于引发这个异常条件的信息。
受检的异常往往指明了可恢复的条件，对于这样的异常，提供一些辅助方法尤其重要，通过这些方法，调用者可以获得一些有助于恢复的信息。
3.避免不必要地使用受检异常
受检异常强迫程序员处理异常的条件，虽然大大增强了可靠性，但过分使用受检的异常会使API使用起来非常不方便。
如果正确地使用API并不能阻止这种异常条件的产生，并且一旦产生异常，使用API的程序员可以立即采取有用的动作，就可认为这种受检异常是必要的，否则，更适合使用未受检异常。
把受检的异常变成未受检的异常的一种做法是：把这个抛出异常的方法分成两个方法，其中第一个方法返回一个boolean，表明是否应该抛出异常：
重构前：
try {
obj.action(args);
} catch (TheCheckedException e) {
... // handle exception condition
}
重构后：
if (obj.actionPermitted(args)) {
obj.action(args);
} else {
... // handle exception condion
}
这种重构并不总是恰当的，但凡是在恰当的地方，它都会使API用起来更加舒服，也更加灵活。
4.优先使用标准的异常
Java平台类库提供了一组基本的未受检异常，它们满足了绝大多数API的异常抛出需求。
重用现有的异常是很有好处的：
- 它使API更加易于学习和使用，因为它与习惯用法是一致的；
- 对于用到这些API的程序而言，可读性会更好，因为它们不会出现很多程序员不熟悉的异常；
- 异常类越少，意味着内存印迹就越小，装载这些类的时间开销也越少。
常用的异常如下：
选择使用哪个异常并不是总是很精确的，有时候它们的使用场合并不相互排斥。
5.抛出与抽象相对应的异常
如果方法抛出的异常与它所执行的任务没有明显的联系，这种情形将会使人不知所措。当方法传递由低层抽象抛出的异常时，往往会发生这种情况。除了使人感到困惑外，这也让实现细节污染了更高层的API。如果高层的实现在后续的发行版本中发生了变化，它所抛出的异常也可能会跟着发生变化，从而潜在地破坏现有的客户端程序。
为避免上述问题，更高层的实现应该捕获底层的异常，同时抛出可以按照高层抽象进行解释的异常。这种做法被称为异常转译。
try {
...
} catch (LowerLevelException e) {
throw new HigherLevelException(...);
}
如JDK源码中AbstractSequentialList类，它是List接口的一个骨架实现类，按照List<E>接口中get方法的规范，需要对其进行异常转译：
public E get(int index) {
ListIterator<E> i = listIterator(index);
try {
return i.next();
} catch (NoSuchElementException e) {
throw new IndexOutOfBoundsException("Index: " + index);
}
}
异常链是一种特殊的异常转译形式，如果低层的异常对于调试导致高层异常的问题非常有帮助，就应该使低层的异常传到高层的异常，高层的异常提供访问方法来获得低层的异常：
try {
...
} catch (LowerLevelException cause) {
throw new HightLevelException(cause);
}
如果不能阻止或处理来自更低层的异常，一般的做法是使用异常转译，除非低层方法碰巧可以保证它抛出的所有异常对高层也合适才可以将异常从低层传播到高层。
异常链对高层和低层异常都提供了最佳的功能：它允许抛出适当的高层异常，同时又能捕获低层的原因进行失败分析。
6.每个方法抛出的异常都要有文档
描述一个方法所抛出的异常，是正确使用这个方法时所需文档的重要组成部分，仔细地为每个方法抛出的异常建立文档是特别重要的。
使用Javadoc的@throws标签记录方法可能抛出的每个未受检异常，但是不要使用throws关键字将未受检的异常包含在方法的声明中。对使用API的程序员来讲，面对受检异常和未受检异常，他们的责任是不同的，要能清晰区分。
要为你编写的每个方法所能抛出的每个异常建立文档。要为每个受检异常提供单独的throws子句，不要为未受检的异常提供throws子句。如果没有为可以抛出的异常建立文档，其他人就很难或根本不可能有效地使用你的类和接口。
7.在细节消息中包含能捕获失败的信息
打印异常信息是为了便于分析失败原因的，这些信息中应该包含有利于分析的细节内容。例如IndexOutOfBoundsException异常的细节消息应该包含下界、上界、没有落在界内的下标值。
与用户层级的错误消息不同，异常的字符串表示法主要是让程序员用来分析失败原因，信息的内容比可理解性重要的多。异常信息包含大量的描述信息往往没有什么意义。
Throwable提供了一些接口供获得相应的异常信息：
提供有助于分析异常的细节信息是非常重要的，因为有些异常情形可能是非常难以复现的。
8.努力使失败保持原子性
当对象抛出异常后，通常我们期望这个对象仍能保持在一种定义良好的可用状态中，因为调用者期望能从这种异常中进行恢复。一般而言，失败的方法调用应该使对象保持在被调用之前的状态。具有这种属性的方法被称为具有失败原子性。
简而言之，方法执行可以失败，但不能破坏对象的状态。
想要获得失败原子性，通常有四种方法：
1. 设计一个不可变的对象
2. 在执行操作之前检查参数的有效性
即在对象被破坏之前，先抛出异常。
//如果不进行检查，从一个empty stack pop元素会破坏对象状态
public Object pop() {
if (size == 0) {
throw new EmptyStackException();
}
Object result = elements[--size];
elements[size] = null;
return result;
}
3. 编写一段恢复代码
由恢复代码来拦截操作过程中发生的失败，并使对象回滚到操作开始之前的状态上。这种办法主要用于永久性的（基于磁盘的）数据结构。
4. 在对象的一份临时拷贝上执行操作
先在对象拷贝数据上进行操作，再用临时拷贝中的结果代替对象的内容。如Collections.sort()：
default void sort(Comparator<? super E> c) {
Object[] a = this.toArray();
Arrays.sort(a, (Comparator) c);
ListIterator<E> i = this.listIterator();
for (Object e : a) {
i.next();
i.set((E) e);
}
}
一般而言，作为方法规范的一部分，产生的任何异常都应该让对象保持在该方法调用之前的状态。如果违反这条规则，API文档就应该清楚地指明对象将会处于什么样的状态。
9.不要忽略异常
声明一个方法可能抛出某个异常的时候，等同于在试图提醒某些可能会发生的一些事情，不应忽略它。
try {
...
} catch (SomeException e) {
}
空的catch块会使异常达不到应有的目的，它会使对象和系统处于一种不确定的状态，出现问题时，也不易追查错误源。
不管异常代表了可预见的异常条目，还是编程错误，用空的catch块忽略它，将会导致程序在遇到错误的情况下继续执行下去，有可能在将来的某个点上导致失败。正确地处理异常能够挽回失败。即使无法挽回，将异常传播给外界，至少会导致程序迅速失败，从而保留有助于调试该失败条件的信息。
