【JAVA 提高班之三】异常处理

Java中异常提供了一种识别及响应错误情况的一致性机制，有效地异常处理能使程序更加健壮、易于调试。异常之所以是一种强大的调试手段，在于其回答了以下三个问题：

• 什么出了错?
• 在哪出的错?
• 为什么出错?

在有效使用异常的情况下，异常类型回答了“什么”被抛出，异常堆栈跟踪回答了“在哪“抛出，异常信息回答了“为什么“会抛出，如果你的异常没有回答以上全部问题，那么可能你没有很好地使用它们。有三个原则可以帮助你在调试过程中最大限度地使用好异常，这三个原则是：

• 具体明确
• 提早抛出
• 延迟捕获

具体明确

在 Java 中，所有的异常都有一个共同的祖先 Throwable（可抛出）。Throwable 指定代码中可用异常传播机制通过 Java 应用程序传输的任何问题的共性。

• Throwable： 有两个重要的子类：Exception（异常）和 Error（错误），二者都是 Java 异常处理的重要子类，各自都包含大量子类。

• Error（错误）:是程序无法处理的错误，表示运行应用程序中较严重问题。大多数错误与代码编写者执行的操作无关，而表示代码运行时 JVM（Java 虚拟机）出现的问题。例如，Java虚拟机运行错误（Virtual MachineError），当 JVM 不再有继续执行操作所需的内存资源时，将出现 OutOfMemoryError。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止。这些错误表示故障发生于虚拟机自身、或者发生在虚拟机试图执行应用时，如Java虚拟机运行错误（Virtual MachineError）、类定义错误（NoClassDefFoundError）等。这些错误是不可查的，因为它们在应用程序的控制和处理能力之 外，而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说，即使确实发生了错误，本质上也不应该试图去处理它所引起的异常状况。在 Java中，错误通过Error的子类描述。

• Exception（异常）:是程序本身可以处理的异常。Exception 类有一个重要的子类 RuntimeException。RuntimeException 类及其子类表示“JVM 常用操作”引发的错误。例如，若试图使用空值对象引用、除数为零或数组越界，则分别引发运行时异常（NullPointerException、ArithmeticException）和 ArrayIndexOutOfBoundException。

注意：异常和错误的区别：异常能被程序本身可以处理，错误是无法处理。

通常，Java的异常(包括Exception和Error)分为可查的异常（checked exceptions）和不可查的异常（unchecked exceptions）。可查异常（编译器要求必须处置的异常）：正确的程序在运行中，很容易出现的、情理可容的异常状况。可查异常虽然是异常状况，但在一定程度上它的发生是可以预计的，而且一旦发生这种异常状况，就必须采取某种方式进行处理。

除了RuntimeException及其子类以外，其他的Exception类及其子类都属于可查异常。这种异常的特点是Java编译器会检查它，也就是说，当程序中可能出现这类异常，要么用try-catch语句捕获它，要么用throws子句声明抛出它，否则编译不会通过。

不可查异常(编译器不要求强制处置的异常):包括运行时异常（RuntimeException与其子类）和错误（Error）。

Exception 这种异常分两大类运行时异常和非运行时异常(编译异常)。程序中应当尽可能去处理这些异常。

运行时异常：都是RuntimeException类及其子类异常，如NullPointerException(空指针异常)、IndexOutOfBoundsException(下标越界异常)等，这些异常是不检查异常，程序中可以选择捕获处理，也可以不处理。这些异常一般是由程序逻辑错误引起的，程序应该从逻辑角度尽可能避免这类异常的发生。

运行时异常的特点是Java编译器不会检查它，也就是说，当程序中可能出现这类异常，即使没有用try-catch语句捕获它，也没有用throws子句声明抛出它，也会编译通过。

提早抛出
异常堆栈信息提供了导致异常出现的方法调用链的精确顺序，包括每个方法调用的类名，方法名，代码文件名甚至行数，以此来精确定位异常出现的现场。

java.lang.NullPointerException
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:103)
at jcheckbook.JCheckbook.readPreferences(JCheckbook.java:225)
at jcheckbook.JCheckbook.startup(JCheckbook.java:116)
at jcheckbook.JCheckbook.<init>(JCheckbook.java:27)
at jcheckbook.JCheckbook.main(JCheckbook.java:318)

以 上展示了FileInputStream类的open()方法抛出NullPointerException的情况。不过注意 FileInputStream.close()是标准Java类库的一部分，很可能导致这个异常的问题原因在于我们的代码本身而不是Java API。所以问题很可能出现在前面的其中一个方法，幸好它也在堆栈信息中打印出来了。

不幸的是，NullPointerException是Java中信息量最少的（却也是最常遭遇且让人崩溃的）异常。它压根不提我们最关心的事情：到底哪里是null。所以我们不得不回退几步去找哪里出了错。

通过逐步回退跟踪堆栈信息并检查代码，我们可以确定错误原因是向readPreferences()传入了一个空文件名参数。既然readPreferences()知道它不能处理空文件名，所以马上检查该条件：

public void readPreferences(String filename)
throws IllegalArgumentException{
    if (filename == null){
         throw new IllegalArgumentException("filename is null");
    }  //if

   //...perform other operations...

   InputStream in = new FileInputStream(filename);

   //...read the preferences file...
}

通过提早抛出异常（又称＂迅速失败＂），异常得以清晰又准确。堆栈信息立即反映出什么出了错（提供了非法参数值），为什么出错（文件名不能为空值），以及哪里出的错（readPreferences()的前部分）。这样我们的堆栈信息就能如实提供：

java.lang.IllegalArgumentException: filename is null
at jcheckbook.JCheckbook.readPreferences(JCheckbook.java:207)
at jcheckbook.JCheckbook.startup(JCheckbook.java:116)
at jcheckbook.JCheckbook.<init>(JCheckbook.java:27)
at jcheckbook.JCheckbook.main(JCheckbook.java:318)

另外，其中包含的异常信息（＂文件名为空＂）通过明确回答什么为空这一问题使得异常提供的信息更加丰富，而这一答案是我们之前代码中抛出的NullPointerException所无法提供的。

通过在检测到错误时立刻抛出异常来实现迅速失败，可以有效避免不必要的对象构造或资源占用，比如文件或网络连接。同样，打开这些资源所带来的清理操作也可以省却。

延迟处理
在方法抛出异常之后，运行时系统将转为寻找合适的异常处理器（exception handler）。潜在的异常处理器是异常发生时依次存留在调用栈中的方法的集合。当异常处理器所能处理的异常类型与方法抛出的异常类型相符时，即为合适 的异常处理器。运行时系统从发生异常的方法开始，依次回查调用栈中的方法，直至找到含有合适异常处理器的方法并执行。当运行时系统遍历调用栈而未找到合适 的异常处理器，则运行时系统终止。同时，意味着Java程序的终止。

菜鸟和高手都可能犯的一个错是，在程序有能力处理异常之前就捕获它。Java编译器通过要求检查出的异常必须被捕获或抛出而间接助长了这种行为。自然而然的做法就是立即将代码用try块包装起来，并使用catch捕获异常，以免编译器报错。

问 题在于，捕获之后该拿异常怎么办？最不该做的就是什么都不做。空的catch块等于把整个异常丢进黑洞，能够说明何时何处为何出错的所有信息都会永远丢失。把异常写到日志中还稍微好点，至少还有记录可查。但我们总不能指望用户去阅读或者理解日志文件和异常信息。让readPreferences()显示错误信息对话框也不合适，因为虽然JCheckbook目前是桌面应用程序，但我们还计划将它变成基于HTML的Web应用。那样的话，显示错误对话框显然不是个选择。同时，不管HTML还是C/S版本，配置信息都是在服务器上读取的，而错误信息需要显示给Web浏览器或者客户端程序。 readPreferences()应当在设计时将这些未来需求也考虑在内。适当分离用户界面代码和程序逻辑可以提高我们代码的可重用性。

在有条件处理异常之前过早捕获它，通常会导致更严重的错误和其他异常。例如，如果上文的readPreferences()方法在调用FileInputStream构造方法时立即捕获和记录可能抛出的FileNotFoundException，代码会变成下面这样：

public void readPreferences(String filename){
   //...

   InputStream in = null;

   // DO NOT DO THIS!!!
try{
    in = new FileInputStream(filename);
}
catch (FileNotFoundException e){
    logger.log(e);
}

in.read(...);

//...
}

上 面的代码在完全没有能力从FileNotFoundException中恢复过来的情况下就捕获了它。如果文件无法找到，下面的方法显然无法读取它。如果 readPreferences()被要求读取不存在的文件时会发生什么情况？当然，FileNotFoundException会被记录下来，如果我们 当时去看日志文件的话，就会知道。然而当程序尝试从文件中读取数据时会发生什么？既然文件不存在，变量in就是空的，一个 NullPointerException就会被抛出。

调试程序时，本能告诉我们要看日志最后面的信息。那将会是NullPointerException，非常让人讨厌的是这个异常非常不具体。错误信息不仅误导我们什么出了错（真正的错误是FileNotFoundException而不是NullPointerException），还误导了错误的出处。真正 的问题出在抛出NullPointerException处的数行之外，这之间有可能存在好几次方法的调用和类的销毁。我们的注意力被这条小鱼从真正的错误处吸引了过来，一直到我们往回看日志才能发现问题的源头。

既然readPreferences() 真正应该做的事情不是捕获这些异常，那应该是什么？看起来有点有悖常理，通常最合适的做法其实是什么都不做，不要马上捕获异常。把责任交给 readPreferences()的调用者，让它来研究处理配置文件缺失的恰当方法，它有可能会提示用户指定其他文件，或者使用默认值，实在不行的话也 许警告用户并退出程序。

把异常处理的责任往调用链的上游传递的办法，就是在方法的throws子句声明异常。在声明可能抛出的异常时，注意越具体越好。这用于标识出调用你方法的程序需要知晓并且准备处理的异常类型。例如，“延迟捕获”版本的readPreferences()可能是这样的：

public void readPreferences(String filename)
throws IllegalArgumentException,
FileNotFoundException, IOException{
    if (filename == null){
           throw new IllegalArgumentException("filename is null");
     }  //if

     //...

     InputStream in = new FileInputStream(filename);

//...
}

技 术上来说，我们唯一需要声明的异常是IOException，但我们明确声明了方法可能抛出FileNotFoundException。 IllegalArgumentException不是必须声明的，因为它是非检查性异常（即RuntimeException的子类）。然而声明它是为 了文档化我们的代码（这些异常也应该在方法的JavaDocs中标注出来）。

当 然，最终你的程序需要捕获异常，否则会意外终止。但这里的技巧是在合适的层面捕获异常，以便你的程序要么可以从异常中有意义地恢复并继续下去，而不导致更 深入的错误；要么能够为用户提供明确的信息，包括引导他们从错误中恢复过来。如果你的方法无法胜任，那么就不要处理异常，把它留到后面捕获和在恰当的层面处理。

我们现在来说说到底该如何处理捕获到的编译时异常：
一、恢复并继续执行：这个结果是最完美的，也是编译时异常出生的目的——捕获异常，并恢复继续执行程序。所以如果你捕获了一个异常是先尽力恢复，这种情况其实就是在主方案行不通时，用备选方案，而且主方案能否行通不能事先知道，必须执行的时候才能知道，所以在一般情况下，备选方案比主方案要的运行结果要差。

二、向上传播异常：向上传播就是在本方法上用throws申明，本方法里的代码不对某异常做任何处理。如果不能用上述恢复措施，就检查能不能向上传播，什么情况下可以向上传播呢？有多种说法，一种说法是当本方法恢复不了时，这个说法显然是错误，因为上层也不一定能恢复。另外还有两种说法是：1.当上层逻辑可以恢复程序时；2.当本方法除了打印之外不能做任何处理，而且不确定上层能否处理。这种两种说法都是正确的，但还不够，因为也有的情况，明确知道上层恢复不了也需要上层处理，所以我认为正确的做法是：当你认为本异常应该由上层处理时，才向上传播。不过这得根据你程序的设计来灵活思考，比如你的类设计了一个上层方法集中处理异常，而下层有一些private方法只是简单的用throws申明。当上层方法捕获到异常时，虽然不能恢复执行，但可以做一些处理，如转换成便于阅读的文本，或者用下面讨论的转译。

三、转译异常：转译即把低层逻辑的异常转化成为高层逻辑的异常，因为有可能低层逻辑的异常在高层逻辑中不能被理解，主要实现是新写一个Exception的子类，然后在低层逻辑捕获异常，改抛这个新写的异常。

四、改抛为运行时异常：这个很好玩，也是一条很方便的处理手法（我常用，我用这个还发现了一个Android系统的bug），即当你捕获到异常时，重新抛出，这跟转译很相似，有一点区别，这里抛的是运行时异常，而转译抛的是编译时异常。那什么时候使用这个手法呢？简单的说就是当某个异常出现时，你必须让程序挂掉。解释一下：如果某个异常情况一旦出现，程序便无法继续执行，而且你明确知道本方法和上层逻辑做不出任何有意义的处理，你只能让程序退出。所以你就抛一个运行时异常让程序挂掉。举个例子，比如在加密通信中，服务器捕获到了一个非法数据异常，这是无法恢复的，而且就是抛一运行异常，让线程挂掉，连接便会自动中断。

五、记录并消耗掉异常：这个手法就是把异常记录下来（到文件或控制台）然后忽略掉异常，有可能随后就让本方法返回null，这个手法一般用在不是很严重的异常，相当于是warning级别的错误，出现这个异常对程序的执行可能影响不太，比如程序的某个偏好设置文件（如窗口位置，最近文件等）损坏，但这个文件信息很少，程序只要使用默认配置即可。

参考文献：
http://www.importnew.com/1701.html
http://blog.csdn.net/hguisu/article/details/6155636
http://redhacker.iteye.com/blog/1924071
http://blog.csdn.net/yanquan345/article/details/19633623