Java异常处理及应用By oldface

2009/03/11

异常是程序运行过程中出现的错误。本次主要讲授的是 Java 语言的异常处理。 Java 语言的异常处理框架，是 Java 语言健壮性的一个重要体现。

Java 把异常当作对象来处理，并定义一个基类java.lang.Throwable 作为所有异常的超类。在Java API 中已经定义了许多异常类，这些异常类分为两大类，错误 Error 和异常 Exception 。 Java异常体系结构呈树状，其层次结构图，如图 1 所示：

异常的概念和 Java异常体系结构

图 1 Java 异常体系结构

Thorwable 类所有异常和错误的超类，有两个子类 Error 和 Exception ，分别表示错误和异常。

其中异常类 Exception 又分为运行时异常(RuntimeException) 和非运行时异常，这两种异常有很大的区别，也称之为不检查异常（ Unchecked Exception ）和检查异常（ Checked Exception ）。

下面将详细讲述这些异常之间的区别与联系：

1 、 Error 与 Exception

Error 是程序无法处理的错误，比如OutOfMemoryError 、 ThreadDeath 等。这些异常发生时， Java 虚拟机（ JVM ）一般会选择线程终止。

Exception 是程序本身可以处理的异常，这种异常分两大类运行时异常和非运行时异常。程序中应当尽可能去处理这些异常。

2 、运行时异常和非运行时异常

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

非运行时异常是 RuntimeException 以外的异常，类型上都属于 Exception 类及其子类。从程序语法角度讲是必须进行处理的异常，如果不处理，程序就不能编译通过。如 IOException 、 SQLException 等以及用户自定义的 Exception 异常，一般情况下不自定义检查异常。

Java 异常的捕获和处理是一个不容易把握的事情，如果处理不当，不但会让程序代码的可读性大大降低，而且导致系统性能低下，甚至引发一些难以发现的错误。

Java 异常处理涉及到五个关键字，分别是： try 、catch 、 finally 、 throw 、 throws 。下面将骤一介绍，通过认识这五个关键字，掌握基本异常处理知识。

异常的捕获和处理

1 、异常处理的基本语法

在 java 中，异常处理的完整语法是：try {

// ( 尝试运行的 ) 程序代码} catch () {

// 异常处理代码} finally {

// 异常发生，方法返回之前，总是要执行的代码}

以上语法有三个代码块：

try 语句块：表示要尝试运行代码， try 语句块中代码受异常监控，其中代码发生异常时，会抛出异常对象。

catch 语句块：会捕获 try 代码块中发生的异常并在其代码块中做异常处理， catch 语句带一个 Throwable 类型的参数，表示可捕获异常类型。当 try 中出现异常时， catch会捕获到发生的异常，并和自己的异常类型匹配，若匹配，则执行 catch 块中代码，并将 catch 块参数指向所抛的异常对象。 catch 语句可以有多个，用来匹配多个中的一个异常，一旦匹配上后，就不再尝试匹配别的 catch 块了。通过异常对象可以获取异常发生时完整的 JVM 堆栈信息，以及异常信息和异常发生的原因等。

finally 语句块：是紧跟 catch 语句后的语句块，这个语句块总是会在方法返回前执行，而不管是否try 语句块是否发生异常。并且这个语句块总是在方法返回前执行。目的是给程序一个补救的机会。这样做也体现了 Java 语言的健壮性。

2 、 try 、 catch 、 finally 三个语句块应注意的问题

try 代码块不能脱离 catch 代码块或 finally 代码块而单独存在 .try 代码块后面至少有一个 catch代码块或 finally 代码块 .

try 代码块后面可以有零个或多个 catch 代码块，还可以有零个或至多一个 finally 代码块。如果catch 代码块和 finally 代码块并存， finally 代码块必须在 catch 代码块后面。

try 代码块后面可以只跟 finally 代码块 .

在 try 代码块中定义的变量的作用域为 try 代码块，在 catch 代码块和 finally 代码块中不能访问该变量。

当 try 代码块后面有多个 catch 代码块时 ,Java 虚拟机会把实际抛出的异常对象依次和各个 catch 代码块声明的异常类型匹配，如果异常对象为某个异常类型或其子类的实例，就执行这个 catch 代码块，而不会再执行共他的 catch 代码块。

如果一个方法可能出现受检查异常，要么用try...catch 语句捕获 . 要么用 throws 子句声明将它抛出，否则会导致编译错误。

throw 语句后面不允许紧跟其他语句 , 因为这些语句永远不会被执行 .

3 、 throw 、 throws 关键字

throw 关键字是用于方法体内部，用来抛出一个Throwable 类型的异常。如果抛出了检查异常，则还应该在方法头部声明方法可能抛出的异常类型。该方法的调用者也必须检查处理抛出的异常。如果所有方法都层层上抛获取的异常，最终 JVM 会进行处理，处理也很简单，就是打印异常消息和堆栈信息。如果抛出的是 Error 或 RuntimeException ，则该方法的调用者可选择处理该异常。有关异常的转译会在下面说明。

throws 关键字用于方法体外部的方法声明部分，用来声明方法可能会抛出某些异常。仅当抛出了检查异常，该方法的调用者才必须处理或者重新抛出该异常。当方法的调用者无力处理该异常的时候，应该继续抛出，而不是囫囵吞枣一般在 catch 块中打印一下堆栈信息做个勉强处理。下面给出一个简单例子，看看如何使用这两个关键字：

public static void main() throws Exception {// 抛出一个检查异常throw new Exception(“ 方法中的

Exception");}

4 、 Throwable 类中的常用方法

getCause() ：返回抛出异常的原因。如果 cause 不存在或未知，则返回 null 。

getMessage() ：返回异常的消息信息。

printStackTrace() ：对象的堆栈跟踪输出至错误输出流，作为字段 System.err 的值。

能处理就早处理，抛出不去还不能处理的就想法消化掉或者转换为 RuntimeException 处理。因为对于一个应用系统来说，抛出大量异常是有问题的，应该从程序开发角度尽可能的控制异常发生的可能。

对于检查异常，如果不能行之有效的处理，还不如转换为 RuntimeException 抛出。这样也让上层的代码有选择的余地――可处理也可不处理。

对于一个应用系统来说，应该有自己的一套异常处理框架，这样当异常发生时，也能得到统一的处理风格，将优雅的异常信息反馈给用户。

异常处理的一般原则

1 、异常转译的原理

所谓的异常转译就是将一种异常转换另一种新的异常，也许这种新的异常更能准确表达程序发生异常。

在 Java 中有个概念就是异常原因，异常原因导致当前抛出异常的那个异常对象，几乎所有带异常原因的异常构造方法都使用 Throwable 类型做参数，这也就为异常的转译提供了直接的支持，因为任何形式的异常和错误都是 Throwable 的子类。

异常的转译与异常链

比如将 SQLException转换为另外一个新的异常 DAOException ，可以这么写：

先自定义一个异常 DAOException ：

public class DAOException extends RuntimeException {

// (省略了部分代码 )public DAOException(String message,

Throwable cause) { super(message, cause);

}}

比如有一个 SQLException 类型的异常对象 e ，要转换为 DAOException ，可以这么写：

DAOException daoException = new DAOException ( "SQL 异常 ", e);

异常转译是针对所有继承 Throwable 超类的类而言的，从编程的语法角度讲 , 其子类之间都可以相互转换。但是，从合理性和系统设计角度考虑，可将异常分为三类：Error 、 Exception 、 RuntimeException ，本人认为，合理的转译关系图应该如图 2 ：

图 2 异常转译

为什么要这么做呢？个人认为，异常的处理存在着一套哲学思想：对于一个应用系统来说，系统所发生的任何异常或者错误对操作用户来说都是系统 " 运行时 " 异常，都是这个应用系统内部的异常。这也是异常转译和应用系统异常框架设计的指导原则。在系统中大量处理非检查异常的负面影响很多，最重要的一个方面就是代码可读性降低，程序编写复杂，异常处理的代码也很苍白无力。因此，很有必要将这些检查异常 Exception 和错误Error转换为 RuntimeException 异常，让程序员根据情况来决定是否捕获和处理所发生的异常。

图中的三条线标识转换的方向，分三种情况：

1 、 Error 到 Exception ：将错误转换为异常，并继续抛出。例如 Spring WEB 框架中，将org.springframework.web.servlet.DispatcherServlet 的 doDispatch() 方法中，将捕获的错误转译为一个 NestedServletException 异常。这样做的目的是为了最大限度挽回因错误发生带来的负面影响。因为一个 Error 常常是很严重的错误，可能会引起系统挂起。

2 、 Exception 到 RuntimeException ：将检查异常转换为 RuntimeException 可以让程序代码变得更优雅，让开发人员集中经理设计更合理的程序代码，反过来也增加了系统发生异常的可能性。

3 、 Error 到 RuntimeException ：目的还是一样的。把所有的异常和错误转译为不检查异常，这样可以让代码更为简洁，还有利于对错误和异常信息的统一处理。

2 、异常链

异常链顾名思义就是将异常发生的原因一个传一个串起来，即把底层的异常信息传给上层，这样逐层抛出。 Java API文档中给出了一个简单的模型：

try {lowLevelOp();

} catch (LowLevelException le) { throw (HighLevelException) new

HighLevelException().initCause(le); }

当程序捕获到了一个底层异常 le ，在处理部分选择了继续抛出一个更高级别的新异常给此方法的调用者。这样异常的原因就会逐层传递。这样，位于高层的异常递归调用 getCause() 方法，就可以遍历各层的异常原因。这就是 Java 异常链的原理。异常链的实际应用很少，发生异常时候逐层上抛不是个好注意，上层拿到这些异常又能奈之何？而且异常逐层上抛会消耗大量资源，因为要保存一个完整的异常链信息。

对于一个应用系统来说，发生所有异常在用户看来都是应用系统内部的异常。因此应该设计一套应用系统的异常框架，以处理系统运行过程中的所有异常。

基于这种观点，可以设计一个应用系统的异常比如叫做NestedRuntimeException 。并且对用户来说，这些异常都是运行应用系统运行时发生的，因此 NestedRuntimeException 应该继承RuntimeException ，这样系统中所有的其他异常都转译为 NestedRuntimeException ，当异常发生的时候，前端接收到 NestedRuntimeException 并做统一的处理。

设计一个高效合理的异常处理框架

图 3 一个应用系统的异常处理框架

画出异常处理框架如图 3 ：

在这个设计图中， NestedRuntimeException 是系统异常的基类，对外只抛出这个异常，这个异常可以由前端（客户端）接收处理，当异常发生时，客户端的相关组件捕获并处理这些异常，将 "友好 " 的信息展示给客户。

在 NestedRuntimeException 下层，有各种各样的异常和错误，最终都转译为NestedRuntimeException ， NestedRuntimeException 下面还可以设计一些别的子类异常，比如 AppDAOException 、 OtherException 等，这些都根据实际需要灵活处理。在往下就是如何将捕获的原始异常比如 SQLException 、 HibernateException转换为更高级一点 AppDAOException 。

有关异常框架设计这方面公认比较好的就是Spring,Spring 中的所有异常都可以用 org.springframework.core.NestedRuntimeException 来表示，并且该基类继承的是 RuntimeException 。Spring 框架很庞大，因此设计了很多NestedRuntimeException 的子类，还有异常转换的工具，这些都是非常优秀的设计思想。

回顾全文，总结一下 Java 异常处理的要点：

异常是程序运行过程过程出现的错误，在 Java 中用类来描述，用对象来表示具体的异常。 Java 将其区分为 Error 与 Exception ， Error 是程序无力处理的错误， Exception 是程序可以处理的错误。异常处理是为了程序的健壮性。

Java 异常类来自于 Java API 定义和用户扩展。通过继承 Java API 异常类可以实现异常的转译。

Java异常处理总结

异常能处理就处理，不能处理就抛出，最终没有处理的异常 JVM 会进行处理。

异常可以传播，也可以相互转译，但应该根据需要选择合理的异常转译的方向。

对于一个应用系统，设计一套良好的异常处理体系很重要。这一点在系统设计的时候就应该考虑到。

把各种不同类型的异常情况进行分类 . 用 Java 类来表示异常情况，这种类被称为异常类 . 把异常情况表示成异常类，可以充分发挥类的可扩展和可重用的优势 .

异常流程的代码和正常流程的代码分离，提高了程序的可读性，简化了程序的结构 .

可以灵活地处理异常，如果当前方法有能力处理异常，就捕获并处理它 . 否则只需要抛出异常，由方法调用者来处理它。

Java异常处理的优点

在当前方法中通过 try...catch 语句捕获并处理异常。

在方法的声明处通过 throws 语句声明抛出异常。

当一个方法正常执行完毕， Java 虚拟机会从调用栈中弹出该方法的栈结构，然后继续处理前一个方法。如果在执行方法的过程中抛出异常，则 Java 虚拟机必须找到能捕获该异常的 catch 代码块 .它首先查看当前方法是否存在这样的 catch 代码块，如果存在，那么就执行该 catch 代码块 ; 否则， Java 虚拟机会从调用栈中弹出该方法的栈结构，继续到前一个方法中查找合适的catch 代码块。

如何处理异常

当 Java 虚拟机追溯到调用栈的底部的方法时 . 如果仍然没有找到处理该异常的代码块，将按以下步骤处理。

(1)调用异常对象的 printStackTtace() 方法，打印来自方法调用栈的异常信息 .

(2) 如果该线程不是主线程，那么终止这个线程，其他线程继续正常运行。如果该线程是主线程 (即方法调用栈的底部为 main() 方法 ) ，那么整个应用程序被终止 .

finally 语句 :任何情况下都必须执行的代码

throws 子句 :声明可能会出现的异常如果一个方法可能会出现异常，但没有能力

处理这种异常，可以在方法声明处用

throws 子句来声明抛出异常。

throw 语句 : 抛出异常

一般来说，在 Java 程序中使用 try..catch 语句不会对应用的性能造成很人的影响。仅仅当异常发生时， Java 虚拟机需要执行额外的操作，来定位处理异常的代码块，这时会对性能产生负面影响。如果抛出异常的代码块和捕获异常的代码块位于同一个方法中，这种影响就会小一些 ; 如果 Java 虚拟机必须搜索方法调用栈来寻找异常处理代码块，对性能的影响就比较大了 .尤其当异常处理代码块位于调用栈的底部时， Java 虚拟机定位异常处理代码块就需要大量的工作。

异常处理对性能的影响

因此，不应该使用异常处理机制来控制程序的正常流程，而应该确保仅仅在程序中可能出现异常的地方使用 try...catch 语句 .

此外，应该使异常处理代码块位于适当的层次 . 如果当前方法具备处理某种异常的能力，就尽量自行处理，不要把自己可以处理的异常推给方法调用者去处理。

异常流程由 try...catch...finally 语句来控制。如果程序中还包含 return 和 System.exit() 句，就会使流程变得更加复杂。

(1) finally 语句不被执行的惟一情况是先执行了用于终止程序的 System.exit() 方法。 java.lang.System 类的静态方法 exit() 用于终止当前的 Java 虚拟机进程， Java 虚拟机所执行的 Java 程序也随之终止 .

异常处理中的 return、System.exit

(2) return 语句用于退出本方法 . 在执行 try 或catch 代码块中的 return 语句时，假如有 finally代码块，会先执行 finally 代码块。

(3) finally 代码块虽然在 return 语句之前被执行，但 finally 代码块不能通过重新给变量赋值的方式来改变 return 语句的返回值 . 就算做了该操作也是无效的。

(4)建议不要在 finally 代码块中使用 return 语句，因为它会导致以下两种潜在的错误。

1 、第一种错误是段盖 try 或 catch 代码块的return 语句。

2 、第二种错误是丢失异常，也就是说 finally 代码块中的 return 语句会令 try 和 catch 代码块的throw 语句失效。

很多人喜欢定义方法的返回类型为 boolean 型的，当方法正确执行，没有出错的时候返回true ，而方法出现出现了问题，返回 false 。这在Java 编程当中是大错而特错的！

方法的返回值只意味着当你的方法调用要返回业务逻辑的处理结果的。如果业务逻辑不带处理结果，那么就是 void 的，不要使用返回值 boolean 来代表方法是否正确执行。

例如

例如 用户登陆方法

boolean login(String username, String password);

很多人喜欢用 boolean 返回，如果是 true ，就是 login了，如果 false 就是没有登陆上。其实是错误的。

还有的人定义返回值为 int 型的，例如如果正确返回就是 0 ，如果用户找不到就是 1 ，如果密码不对，就是 2

int login(String username, String password);

然后在主程序里面写一个 ifelse 来判断不同的流程。

int logon = UserManager.login(xx, xx);

if (logon ==0)  {  ...  }else if (logon == 1)  {  ...  }else if (logon ==2) {  ..}  

这是面向过程的编程逻辑，不是面向对象的编程逻辑。

应该这样来写： User login(String username, String password); throws UserNotFoundException, PasswordNotMatchException;

主程序这样来写：

try {userService.login(xx, xx);....   // 用户登陆以后的主事件流代码

} catch (NoSuchUserException e) {….// 用户不存在的事件处理，例如产生一个提示

用户注册的页面} catch (PasswordNotMatchException e) {

....// 密码不对的事件处理，例如 forward 到重

新登陆的页面}  

在使用 UseCase 来描述一个场景的时候，有一个主事件流和 n 个异常流。异常流可能发生在主事件流的过程，而 try 语句里面实现的是主事件流， catch里面实现的是异常流，在这里Exception不代表程序出现了异常或者错误， Exception 只是面向对象化的业务逻辑控制方法。如果没有明白这一点，那么我认为并没有真正明白应该怎么使用 Java 来正确的编程。

我们会自定义大量的 Exception 类，所有这些 Exception 类都不意味着程序出现了异常或者错误，只是代表非主事件流的发生的，用来进行那些分支流程的流程控制的。例如你往权限系统中增加一个用户，应该定义 1 个异常类， UserExistedException ，抛出这个异常不代表你插入动作失败，只说明你碰到一个分支流程，留待后面的 catch 中来处理这个分支流程。传统的程序员会写一个 if else 来处理，而一个合格的 OOP 程序员应该有意识的使用 try catch 方式来区分主事件流和 n 个分支流程的处理，通过 try catch ，而不是 if else 来从代码上把不同的事件流隔离开来进行分别的代码撰写。