java异常处理

只针对不正常的条件才使用异常

异常只应该被用于不正常的条件，它们永远不应被用于正常的控制流。

下面是一个用异常作遍历结束条件的滥用异常的例子：

//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提供了三种可抛出的异常：[color=red]被检查的异常（checkedException）、运行时异常（run-time Exception）和错误(error)。[/color]　　如果期望调用者在调用时出现的异常能够恢复，则应该使用被检查的异常，通过抛出一个被检查的异常，强迫调用者在catch中处理该异常，或者将异常传播到外面。
　　对于一个方法声明要抛出的每一个被检查的异常，它是对API用户的一种潜在指示：与异常相关联的条件是调用这次个方法的一种可能结果。
　　两种未被检查的可抛出结构：运行时异常和错误，在行为上相同的，它们都不需要、也不应该被捕获的抛出物。你所实现的所有未被检查的抛出结构都应是 RuntimeException的子类。定义一个非Exception、RuntimeException或Error子类的抛出物是可行的，但从行为意义上它等同于被普通的被检查异常（即Exception子类而非RuntimeException子类）.

避免不必要地使用被检查的异常
与返回代码不同，被检查的异常强迫程序处理例外的情况，从而大大地提高了程序的可靠性。而过分地使用被检查的异常，则增加了不可忽视的负担。如果正确地使用API并不能阻止这种异常条件的产生，并且一旦产生了异常，使用API的程序可以采取有用的动作，那么这种负担被认为是正当的。

try{
   ...
}catch(TheCheckedException e){
   e.printStackTree();
   System.exit(1);
} 

　　如果使用API的程序员无法做得比这更好，那么未被检查的异常可能更为合适。在实践中，catch几乎总有断言失败的特征。
　　“把被检查的异常变成未被检查的异常”的一种技术是，把这个要抛出异常的方法分成两个方法，第一个方法返回一个boolean以指明是否要抛出异常，另一个执行真正的功能，如果条件不满足就抛异常。如下：

//Invocation with checked exception
try{
   obj.action(args);
}catch(TheCheckedException e){
   //Handle exception condition
} 
　　转换为：
//Invocation with state-testing method and unchecked exception
if(obj.actionPermitted(args)){
   obj.action(args));
}else{
   //handle exception condition
} 

　　当然这种转换并不总是合适的，例如一对象将在缺少外部同步的情况下被并发访问，或者可被外界改变状态，那么这种转换将是不合适的。
尽量使用标准的异常
Java平台库中讫今为止最常被重用的异常如下：
IllegalArgumentException 参数值不合适
IllegalStateException 对于这个方法调用而言，对象的状态不合适(如初始化不恰当)
NullPointerException 在null被禁止的情况下参数值为null
IndexOutOfBoundsException 下标越界
ConcurrentModificationException 在禁止并发修改的情况下，对象检测到并发修改
UnsupportedOperationException 对象不支持客户请求的方法
其它的异常也可以使用，只要确保抛出异常的条件与文档要求一致即可。

抛出的异常要适合于相应的抽象
　　高层的实现，应该捕获低层的异常，同时抛出一个可以按照高层抽象进行解释的异常，这种做法叫做 [color=red]异常转译(exception translation)[/color]。即如：

//exception translation!
try{
  //use lowlevel abstraction to do our bidding
  ...
}catch(LowerLevelException e){
  throw new HigherLevelException(...);
} 

　　低层的异常被高层的异常保存起来，且高层的异常提供一个公有的访问方法来获得低层的异常，这种做叫做异常链接(exception chaining)。
//Exception chaining.
try{
//use lower-level abstraction to do our bindding
...
}catch(LowerLevelException e){
throw new HigherLevelException(e);
}
　　异常链的实现非常简单，在1.4及以后版本中，可以通过Throwable来获得支持。

//Exception chaining in release 1.4 or later
HigherLevelException(Throwable t){
  super(t);
} 

处理来自低层的异常，
最好的做法是，在调用低层方法之前通过一些检查等手段来确保它们会成功执行；
其次的做法是，让高层处理这些异常，从而将高层方法的调用者与低层的问题隔离开；
一般的做法是使用异常转译；
如果低层方法的异常对高层也是合适的，则将其从低层传到高层。

每个方法抛出的异常都要有文档
总是要单独地声明被检查的异常，并且利用javadoc的@throws标记，准确地记录下每个异常被抛出的条件。
使用javadoc的@throws标签积累下一个方法可能会抛出的每个未被检查的异常，但是不要使用throws关键字将未被检查的异常包含在方法的声明中。
如果一个类中的许多方法出于同样的原因而抛出同一个异常，那么在该类的文档注释中对这个异常做文档，而不是为每个方法单独写一个文档。

在细节消息中包含失败 - 捕获信息
为了捕获失败，异常信息应该尽可能多的包含有意义的参数和域的值，如：IndexOutOfBoundsException应该包括上界、下界以及实际的下标。

努力使失败保持原子性
一个失败的方法调用应该使对象保持“它在被调用之前的状态”，方法如下：
① 使用非可变对象；
② 在可变对象上的操作，应在执行前检查参数的有效性；
③ 写一段恢复代码，在执行失败的情况下，回滚到操作开始之前的状态（不常用）；
④ 在对象的一份临时拷贝上执行操作，当完成之后，再把临时拷贝中的结果复制给原来的对象，如Collections.sort在执行排序之前，先把它的输入转储到一个数组中，这样既能降低内循环的开销，又能保证在排序失败的时候，输入列表将保持原样。

不要忽略异常
除非有特殊的需求（如动画中的多帧图像播放），否则不要吃掉异常，至少在catch块中包含一条说明，用来解释为什么忽略这个异常。简单地将一个未被检查的异常传播到外界至少会使程序迅速地失败，从而保留了有助于调试该失败条件信息，比异常被忽略后的一个不可预测的时刻程序失败这种情况要强。