只针对不正常的条件才使用异常
异常只应该被用于不正常的条件，它们永远不应被用于正常的控制流。
下面是一个用异常作遍历结束条件的滥用异常的例子：
//horrible abuse of exceptions. Don't ever do this!
try{
int i=0;
while(true)a[i++].f();
}catch(ArrayIndexOutOfBoundsException e){
...
}
其错有三：
1、创建、抛出和捕获异常的开销是很昂贵的。因为它的初衷是用于不正常的情形，少有jvm会它进行性能优化。
2、把代码放在try-catch中会阻止jvm实现本来可能要执行的某些特定的优化。
3、有些现代的jvm对循环进行优化，不会出现冗余的检查。
完全可以使用标准的实现方式：
for(int i=0;i<a.length;i++){
a[i].f();
}
这条原则也适用于API设计。一个设计良好的API不应该强迫它的客户为了正常的控制流而使用异常。如果类中有一个”状态相关”的方法，即只有特定的条件下可被调用的方法，则这个类也应有一个单独的“状态测试”方法，以为调用这个状态相关方法前的检查。如Collection类的next方法和 hasNext方法。
for(Iterator i=collection.iterator();i.hasNext();){
Foo foo=(Foo)i.next();
...
}
对于可恢复的条件使用被检查的异常，对于程序错误使用运行时异常
java提供了三种可抛出的异常：被检查的异常（checkedException）、运行时异常（run-time Exception）和错误(error)。 如果期望调用者在调用时出现的异常能够恢复，则应该使用被检查的异常，通过抛出一个被检查的异常，强迫调用者在catch中处理该异常，或者将异常传播到外面。
对于一个方法声明要抛出的每一个被检查的异常，它是对API用户的一种潜在指示：与异常相关联的条件是调用这次个方法的一种可能结果。
两种未被检查的可抛出结构：运行时异常和错误，在行为上相同的，它们都不需要、也不应该被捕获的抛出物。你所实现的所有未被检查的抛出结构都应是 RuntimeException的子类。定义一个非Exception、RuntimeException或Error子类的抛出物是可行的，但从行为意义上它等同于被普通的被检查异常（即Exception子类而非RuntimeException子类）.
避免不必要地使用被检查的异常
与返回代码不同，被检查的异常强迫程序处理例外的情况，从而大大地提高了程序的可靠性。而过分地使用被检查的异常
