J2EE项目异常处理

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

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

Java把异常当作对象来处理，并定义一个基类java.lang.Throwable作为所有异常的超类。

在Java API中已经定义了许多异常类，这些异常类分为两大类，错误Error和异常Exception。

Java异常体系结构呈树状，其层次结构图如图 1所示：



图 1 Java异常体系结构

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

其中异常类Exception又分为运行时异常(RuntimeException)和非运行时异常，

这两种异常有很大的区别，也称之为不检查异常（Unchecked Exception）

和检查异常（Checked Exception）。下面将详细讲述这些异常之间的区别与联系：

1、Error与Exception

Error（错误）表示运行应用程序中较严重问题, 是程序无法处理的错误。大多数错误与代码编写者执行的操作无关，而表示代码运行时 JVM（Java 虚拟机）出现的问题。比如OutOfMemoryError、ThreadDeath等。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止。

Exception（异常）是应用程序中可能的可预测、可恢复问题。一般大多数异常表示中度到轻度的问题。异常一般是在特定环境下产生的，通常出现在代码的特定方法和操作中。在 EchoInput 类中，当试图调用 readLine 方法时，可能出现 IOException 异常。

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

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

Exception是程序本身可以处理的异常，这种异常分两大类运行时异常和非运行时异常。

程序中应当尽可能去处理这些异常。

运行时异常都是RuntimeException类及其子类异常，如NullPointerException、IndexOutOfBoundsException等，

这些异常是不检查异常，程序中可以选择捕获处理，也可以不处理。这些异常一般是由程序逻辑错误引起的，

程序应该从逻辑角度尽可能避免这类异常的发生。

非运行时异常是RuntimeException以外的异常，类型上都属于Exception类及其子类。

从程序语法角度讲是必须进行处理的异常，如果不处理，程序就不能编译通过。

如IOException、SQLException等以及用户自定义的Exception异常，一般情况下不自定义检查异常。

为什么要在J2EE项目中谈异常处理呢？

可能许多java初学者都想说：“异常处理不就是try….catch…finally吗？这谁都会啊！”。笔者在初学java时也是这样认为的。如何在一个多层的j2ee项目中定义相应的异常类？在项目中的每一层如何进行异常处理？异常何时被抛出？异常何时被记录？异常该怎么记录？何时需要把checked Exception转化成unchecked Exception ，何时需要把unChecked Exception转化成checked Exception?异常是否应该呈现到前端页面？如何设计一个异常框架？本文将就这些问题进行探讨。

JAVA异常处理

在面向过程式的编程语言中，我们可以通过返回值来确定方法是否正常执行。比如在一个c语言编写的程序中，如果方法正确的执行则返回1.错误则返回0。在vb或delphi开发的应用程序中，出现错误时，我们就弹出一个消息框给用户。

通过方法的返回值我们并不能获得错误的详细信息。可能因为方法由不同的程序员编写，当同一类错误在不同的方法出现时，返回的结果和错误信息并不一致。

所以java语言采取了一个统一的异常处理机制。

什么是异常？运行时发生的可被捕获和处理的错误。

在java语言中，Exception是所有异常的父类。任何异常都扩展于Exception类。Exception就相当于一个错误类型。如果要定义一个新的错误类型就扩展一个新的Exception子类。采用异常的好处还在于可以精确的定位到导致程序出错的源代码位置,并获得详细的错误信息。

Java异常处理通过五个关键字来实现，try,catch,throw ,throws, finally。具体的异常处理结构由try….catch….finally块来实现。try块存放可能出现异常的java语句，catch用来捕获发生的异常，并对异常进行处理。Finally块用来清除程序中未释放的资源。不管理try块的代码如何返回，finally块都总是被执行。

一个典型的异常处理代码

java 代码

public String getPassword(String userId)throws DataAccessException{

String sql = “select password from userinfo where userid=’”+userId +”’”;

String password = null;

Connection con = null;

Statement s = null;

ResultSet rs = null;

try{

con = getConnection();//获得数据连接

s = con.createStatement();

rs = s.executeQuery(sql);

while(rs.next()){

password = rs.getString(1);

}

rs.close();

s.close();

}

Catch(SqlException ex){

throw new DataAccessException(ex);

}

finally{

try{

if(con != null){

con.close();

}

}

Catch(SQLException sqlEx){

throw new DataAccessException(“关闭连接失败!”,sqlEx);

}

}

return password;

}

Java的异常处理机制具有的优势：

给错误进行了统一的分类，通过扩展Exception类或其子类来实现。从而避免了相同的错误可能在不同的方法中具有不同的错误信息。在不同的方法中出现相同的错误时，只需要throw 相同的异常对象即可。

获得更为详细的错误信息。通过异常类，可以给异常更为详细，对用户更为有用的错误信息。以便于用户进行跟踪和调试程序。

把正确的返回结果与错误信息分离。降低了程序的复杂度。调用者无需要对返回结果进行更多的了解。

强制调用者进行异常处理，提高程序的质量。当一个方法声明需要抛出一个异常时，那么调用者必须使用try….catch块对异常进行处理。当然调用者也可以让异常继续往上一层抛出。

Java的checked和unchecked异常

Java异常分为两种类型，checked异常和unchecked异常，另一种叫法是异常和错误。

所有继承java.lang.Exception 的异常都属于checked异常。所有继承java.lang.RuntimeException的异常都属于unChecked异常。

简单地讲，checked是可以在执行过程中恢复的，而unchecked异常则是无法处理的错误。

checked异常：

表示无效，不是程序中可以预测的。比如无效的用户输入，文件不存在，网络或者数据库链接错误。这些都是外在的原因，都不是程序内部可以控制的。

必须在代码中显式地处理。比如try-catch块处理，或者给所在的方法加上throws说明，将异常抛到调用栈的上一层。

继承自java.lang.Exception（java.lang.RuntimeException除外）。

当一个方法去调用一个可能抛出checked异常的方法，必须通过try…catch块对异常进行捕获进行处理或者重新抛出。

我们看看Connection接口的createStatement()方法的声明。

public Statement createStatement() throws SQLException;

SQLException是checked异常。当调用createStatement方法时，java强制调用者必须对SQLException进行捕获处理。

java 代码

public String getPassword(String userId){

try{

……

Statement s = con.createStatement();

……

Catch(SQLException sqlEx){

……

}

……

}

或者

java 代码

public String getPassword(String userId)throws SQLException{

Statement s = con.createStatement();

}

(当然，像Connection,Satement这些资源是需要及时关闭的，这里仅是为了说明checked 异常必须强制调用者进行捕获或继续抛出)

unchecked异常：

表示错误，程序的逻辑错误。是RuntimeException的子类，比如IllegalArgumentException, NullPointerException和IllegalStateException。

不需要在代码中显式地捕获unchecked异常做处理。

继承自java.lang.RuntimeException（而java.lang.RuntimeException继承自java.lang.Exception）。

Java中的checked异常需要在代码中显式地通过try-catch捕获或者再抛出，如果不需要对这个异常做处理，可以简地将异常再次抛出，这种异常存在一点不足，很多人习惯在代码中直接写一个空的catch块，这样不但使代码变得有些冗余和“丑陋”，而且给调试带来麻烦，增加了代码维护的难度。所以有人说checked使代码变的冗长，空的catch块也没什么意义，所以checked异常应该从Java标准中去除，像C#中就没有checked异常的概念，C#中不强制显式地捕获异常。

Java异常之所以会分为这两种，应该是出于如下考虑：

checked异常可以帮助开发人员意识到哪一行有可能会出现异常，因为Java的API已经说明了调用哪些方法可能会抛出异常。如果不做处理编译就不能通过，从某种程度上说，这种做法可以避免程序的一些错误。

unChecked异常也称为运行时异常，通常RuntimeException都表示用户无法恢复的异常，如无法获得数据库连接，不能打开文件等。虽然用户也可以像处理checked异常一样捕获unChecked异常。但是如果调用者并没有去捕获unChecked异常时，编译器并不会强制你那么做。

比如一个把字符转换为整型数值的代码如下：

java 代码

String str = “123”;

int value = Integer.parseInt(str);

parseInt的方法签名为：

java 代码

public static int parseInt(String s) throws NumberFormatException

当传入的参数不能转换成相应的整数时，将会抛出NumberFormatException。因为NumberFormatException扩展于RuntimeException，是unChecked异常。所以调用parseInt方法时无需要try…catch

选择checked还是unchecked异常？

一些Java书籍建议使用checked异常处理程序中所有可恢复的异常，而用unchecked异常作为无法恢复的错误。但是实际上那些继承自RuntimeException的Java异常大多也可以在程序中恢复的，比如NullPointerException、IllegalArgumentExceptions、除0异常等等都可以通过捕获处理使程序继续运行。只有一些特殊情况会破坏程序的执行，比如启动的时候读取配置文件，如果配置文件不存在或者有严重错误，程序只好退出。

以下是是支持和反对checked异常的一些观点：

编译器强制捕获或者抛出unchecked异常使开发人员时刻记着要处理异常。

抛出checked异常的方法必须声明throws，throws成为了方法或者接口的一部分，给后续版本增加或者修改方法的异常带来不便。

unchecked异常不需要显式地处理反而使异常处理变的困难。

调用checked异常的方法，就必须处理这个方法的异常，这使得上层的调用者代码混乱。

选择checked还是unchecked都是由你自己决定的，很难说哪种就一定正确，反之就一定错误。目前比较流行的语言中，Java似乎是唯一支持checked异常的语言，其他语言都只有unchecked异常。

因为java不强制调用者对unChecked异常进行捕获或往上抛出。所以程序员总是喜欢抛出unChecked异常。或者当需要一个新的异常类时，总是习惯的从RuntimeException扩展。当你去调用它些方法时，如果没有相应的catch块，编译器也总是让你通过,同时你也根本无需要去了解这个方法倒底会抛出什么异常。看起来这似乎倒是一个很好的办法，但是这样做却是远离了java异常处理的真实意图。并且对调用你这个类的程序员带来误导，因为调用者根本不知道需要在什么情况下处理异常。而checked异常可以明确的告诉调用者，调用这个类需要处理什么异常。如果调用者不去处理，编译器都会提示并且是无法编译通过的。当然怎么处理是由调用者自己去决定的。

所以Java推荐人们在应用代码中应该使用checked异常。就像我们在上节提到运用异常的好外在于可以强制调用者必须对将会产生的异常进行处理。包括在《java Tutorial》等java官方文档中都把checked异常作为标准用法。

使用checked异常，应意味着有许多的try…catch在你的代码中。当在编写和处理越来越多的try…catch块之后，许多人终于开始怀疑checked异常倒底是否应该作为标准用法了。

甚至连大名鼎鼎的《thinking in java》的作者Bruce Eckel也改变了他曾经的想法。Bruce Eckel甚至主张把unChecked异常作为标准用法。并发表文章，以试验checked异常是否应该从java中去掉。Bruce Eckel语：“当少量代码时，checked异常无疑是十分优雅的构思，并有助于避免了许多潜在的错误。但是经验表明，对大量代码来说结果正好相反”

使用checked异常会带来许多的问题。

checked异常导致了太多的try…catch 代码

可能有很多checked异常对开发人员来说是无法合理地进行处理的，比如SQLException。而开发人员却不得不去进行try…catch。当开发人员对一个checked异常无法正确的处理时，通常是简单的把异常打印出来或者是干脆什么也不干。特别是对于新手来说，过多的checked异常让他感到无所适从。

java 代码

try{

……

Statement s = con.createStatement();

……

Catch(SQLException sqlEx){

sqlEx.PrintStackTrace();

}

或者

try{

……

Statement s = con.createStatement();

……

Catch(SQLException sqlEx){

//什么也不干

}

checked异常导致了许多难以理解的代码产生

当开发人员必须去捕获一个自己无法正确处理的checked异常，通常的是重新封装成一个新的异常后再抛出。这样做并没有为程序带来任何好处。反而使代码晚难以理解。

就像我们使用JDBC代码那样，需要处理非常多的try…catch.，真正有用的代码被包含在try…catch之内。使得理解这个方法变理困难起来

checked异常导致异常被不断的封装成另一个类异常后再抛出

java 代码

public void methodA()throws ExceptionA{

…..

throw new ExceptionA();

}

public void methodB()throws ExceptionB{

try{

methodA();

……

}catch(ExceptionA ex){

throw new ExceptionB(ex);

}

}

Public void methodC()throws ExceptinC{

try{

methodB();

…

}

catch(ExceptionB ex){

throw new ExceptionC(ex);

}

}

我们看到异常就这样一层层无休止的被封装和重新抛出。

checked异常导致破坏接口方法

一个接口上的一个方法已被多个类使用，当为这个方法额外添加一个checked异常时，那么所有调用此方法的代码都需要修改。

可见上面这些问题都是因为调用者无法正确的处理checked异常时而被迫去捕获和处理，被迫封装后再重新抛出。这样十分不方便，并不能带来任何好处。在这种情况下通常使用unChecked异常。

chekced异常并不是无一是处，checked异常比传统编程的错误返回值要好用得多。通过编译器来确保正确的处理异常比通过返回值判断要好得多。

如果一个异常是致命的，不可恢复的。或者调用者去捕获它没有任何益处，使用unChecked异常。

如果一个异常是可以恢复的，可以被调用者正确处理的，使用checked异常。

在使用unChecked异常时，必须在在方法声明中详细的说明该方法可能会抛出的unChekced异常。由调用者自己去决定是否捕获unChecked异常

倒底什么时候使用checked异常，什么时候使用unChecked异常？并没有一个绝对的标准。但是笔者可以给出一些建议

当所有调用者必须处理这个异常，可以让调用者进行重试操作；或者该异常相当于该方法的第二个返回值。使用checked异常。

这个异常仅是少数比较高级的调用者才能处理，一般的调用者不能正确的处理。使用unchecked异常。有能力处理的调用者可以进行高级处理，一般调用者干脆就不处理。

这个异常是一个非常严重的错误，如数据库连接错误，文件无法打开等。或者这些异常是与外部环境相关的。不是重试可以解决的。使用unchecked异常。因为这种异常一旦出现，调用者根本无法处理。

如果不能确定时，使用unchecked异常。并详细描述可能会抛出的异常,以让调用者决定是否进行处理。

设计一个新的异常类

在设计一个新的异常类时，首先看看是否真正的需要这个异常类。一般情况下尽量不要去设计新的异常类，而是尽量使用java中已经存在的异常类。

如

java 代码

IllegalArgumentException, UnsupportedOperationException

不管是新的异常是chekced异常还是unChecked异常。我们都必须考虑异常的嵌套问题。

java 代码

public void methodA()throws ExceptionA{

…..

throw new ExceptionA();

}

方法methodA声明会抛出ExceptionA.

public void methodB()throws ExceptionB

methodB声明会抛出ExceptionB,当在methodB方法中调用methodA时，ExceptionA是无法处理的,所以ExceptionA应该继续往上抛出。一个办法是把methodB声明会抛出ExceptionA.但这样已经改变了MethodB的方法签名。一旦改变，则所有调用methodB的方法都要进行改变。

另一个办法是把ExceptionA封装成ExceptionB，然后再抛出。如果我们不把ExceptionA封装在ExceptionB中，就丢失了根异常信息，使得无法跟踪异常的原始出处。

java 代码

public void methodB()throws ExceptionB{

try{

methodA();

……

}catch(ExceptionA ex){

throw new ExceptionB(ex);

}

}

如上面的代码中，ExceptionB嵌套一个ExceptionA.我们暂且把ExceptionA称为“起因异常”,因为ExceptionA导致了ExceptionB的产生。这样才不使异常信息丢失。

所以我们在定义一个新的异常类时，必须提供这样一个可以包含嵌套异常的构造函数。并有一个私有成员来保存这个“起因异常”。

java 代码

public Class ExceptionB extends Exception{

private Throwable cause;

public ExceptionB(String msg, Throwable ex){

super(msg);

this.cause = ex;

}

public ExceptionB(String msg){

super(msg);

}

public ExceptionB(Throwable ex){

this.cause = ex;

}

}

当然，我们在调用printStackTrace方法时，需要把所有的“起因异常”的信息也同时打印出来。所以我们需要覆写printStackTrace方法来显示全部的异常栈跟踪。包括嵌套异常的栈跟踪。

java 代码

public void printStackTrace(PrintStrean ps){

if(cause == null){

super.printStackTrace(ps);

}else{

ps.println(this);

cause.printStackTrace(ps);

}

}

一个完整的支持嵌套的checked异常类源码如下。我们在这里暂且把它叫做NestedException

java 代码

public NestedException extends Exception{

private Throwable cause;

public NestedException (String msg){

super(msg);

}

public NestedException(String msg, Throwable ex){

super(msg);

This.cause = ex;

}

public Throwable getCause(){

return (this.cause == null ? this :this.cause);

}

public getMessage(){

String message = super.getMessage();

Throwable cause = getCause();

if(cause != null){

message = message + “;nested Exception is ” + cause;

}

return message;

}

public void printStackTrace(PrintStream ps){

if(getCause == null){

super.printStackTrace(ps);

}else{

ps.println(this);

getCause().printStackTrace(ps);

}

}

public void printStackTrace(PrintWrite pw){

if(getCause() == null){

super.printStackTrace(pw);

}

else{

pw.println(this);

getCause().printStackTrace(pw);

}

}

public void printStackTrace(){

printStackTrace(System.error);

}

}

同样要设计一个unChecked异常类也与上面一样。只是需要继承RuntimeException。

如何记录异常

作为一个大型的应用系统都需要用日志文件来记录系统的运行，以便于跟踪和记录系统的运行情况。系统发生的异常理所当然的需要记录在日志系统中。

java 代码

public String getPassword(String userId)throws NoSuchUserException{

UserInfo user = userDao.queryUserById(userId);

If(user == null){

Logger.info(“找不到该用户信息,userId=”+userId);

throw new NoSuchUserException(“找不到该用户信息,userId=”+userId);

}

else{

return user.getPassword();

}

}

public void sendUserPassword(String userId)throws Exception {

UserInfo user = null;

try{

user = getPassword(userId);

//……..

sendMail();

//

}catch(NoSuchUserException ex)(

logger.error(“找不到该用户信息:”+userId+ex);

throw new Exception(ex);

}

我们注意到，一个错误被记录了两次.在错误的起源位置我们仅是以info级别进行记录。而在sendUserPassword方法中，我们还把整个异常信息都记录了。

笔者曾看到很多项目是这样记录异常的，不管三七二一，只有遇到异常就把整个异常全部记录下。如果一个异常被不断的封装抛出多次，那么就被记录了多次。那么异常倒底该在什么地方被记录？

异常应该在最初产生的位置记录！

如果必须捕获一个无法正确处理的异常，仅仅是把它封装成另外一种异常往上抛出。不必再次把已经被记录过的异常再次记录。

如果捕获到一个异常，但是这个异常是可以处理的。则无需要记录异常

java 代码

public Date getDate(String str){

Date applyDate = null;

SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);

try{

applyDate = format.parse(applyDateStr);

}

catch(ParseException ex){

//乎略，当格式错误时，返回null

}

return applyDate;

}

捕获到一个未记录过的异常或外部系统异常时，应该记录异常的详细信息

java 代码

try{

……

String sql=”select * from userinfo”;

Statement s = con.createStatement();

……

Catch(SQLException sqlEx){

Logger.error(“sql执行错误”+sql+sqlEx);

}

究竟在哪里记录异常信息，及怎么记录异常信息，可能是见仁见智的问题了。甚至有些系统让异常类一记录异常。当产生一个新异常对象时，异常信息就被自动记录。

java 代码

public class BusinessException extends Exception {

private void logTrace() {

StringBuffer buffer=new StringBuffer();

buffer.append("Business Error in Class: ");

buffer.append(getClassName());

buffer.append(",method: ");

buffer.append(getMethodName());

buffer.append(",messsage: ");

buffer.append(this.getMessage());

logger.error(buffer.toString());

}

public BusinessException(String s) {

super(s);

race();

}

这似乎看起来是十分美妙的，其实必然导致了异常被重复记录。同时违反了“类的职责分配原则”，是一种不好的设计。记录异常不属于异常类的行为，记录异常应该由专门的日志系统去做。并且异常的记录信息是不断变化的。我们在记录异常同应该给更丰富些的信息。以利于我们能够根据异常信息找到问题的根源，以解决问题。

虽然我们对记录异常讨论了很多，过多的强调这些反而使开发人员更为疑惑，一种好的方式是为系统提供一个异常处理框架。由框架来决定是否记录异常和怎么记录异常。而不是由普通程序员去决定。但是了解些还是有益的。

异常处理的分类

Java异常分类

Java 异常可分为可检测异常，非检测异常和自定义异常。

可检测异常

可检测异常经编译器验证，对于声明抛出异常的任何方法，编译器将强制执行处理或声明规则，例如：sqlExecption 这个异常就是一个检测异常。你连接 JDBC 时，不捕捉这个异常，编译器就通不过，不允许编译。

非检测异常

非检测异常不遵循处理或声明规则。在产生此类异常时，不一定非要采取任何适当操作，编译器不会检查是否已解决了这样一个异常。例如：一个数组为 3 个长度，当你使用下标为３时，就会产生数组下标越界异常。这个异常 JVM 不会进行检测，要靠程序员来判断。有两个主要类定义非检测异常：RuntimeException 和 Error。

Error 子类属于非检测异常，因为无法预知它们的产生时间。若 Java 应用程序内存不足，则随时可能出现 OutOfMemoryError；起因一般不是应用程序的特殊调用，而是 JVM 自身的问题。另外，Error 一般表示应用程序无法解决的严重问题。

RuntimeException 类也属于非检测异常，因为普通 JVM 操作引发的运行时异常随时可能发生，此类异常一般是由特定操作引发。但这些操作在 Java 应用程序中会频繁出现。因此，它们不受编译器检查与处理或声明规则的限制。

自定义异常

自定义异常是为了表示应用程序的一些错误类型，为代码可能发生的一个或多个问题提供新含义。可以显示代码多个位置之间的错误的相似性，也可以区分代码运行时可能出现的相似问题的一个或者多个错误，或给出应用程序中一组错误的特定含义。例如，对队列进行操作时，有可能出现两种情况：空队列时试图删除一个元素；满队列时试图添加一个元素。则需要自定义两个异常来处理这两种情况。

异常的捕获和处理

Java异常的捕获和处理是一个不容易把握的事情，如果处理不当，不但会让程序代码的可读性大大降低，

而且导致系统性能低下，甚至引发一些难以发现的错误。

Java异常处理涉及到五个关键字，分别是：try、catch、finally、throw、throws。下面将骤一介绍，

通过认识这五个关键字，掌握基本异常处理知识。

1、 异常处理的基本语法

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

Java代码

try{

//（尝试运行的）程序代码

}catch(异常类型 异常的变量名){

//异常处理代码

}finally{

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

}

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、

try...finally三种结构，catch语句可以有一个或多个，finally语句最多一个。

第二、try、catch、finally三个代码块中变量的作用域为代码块内部，分别独立而不能相互访问。

如果要在三个块中都可以访问，则需要将变量定义到这些块的外面。

第三、多个catch块时候，只会匹配其中一个异常类并执行catch块代码，而不会再执行别的catch块，

并且匹配catch语句的顺序是由上到下。

3、throw、throws关键字

throw关键字是用于方法体内部，用来抛出一个Throwable类型的异常。如果抛出了检查异常，

则还应该在方法头部声明方法可能抛出的异常类型。该方法的调用者也必须检查处理抛出的异常。

如果所有方法都层层上抛获取的异常，最终JVM会进行处理，处理也很简单，就是打印异常消息和堆栈信息。

如果抛出的是Error或RuntimeException，则该方法的调用者可选择处理该异常。有关异常的转译会在下面说明。

throws关键字用于方法体外部的方法声明部分，用来声明方法可能会抛出某些异常。仅当抛出了检查异常，

该方法的调用者才必须处理或者重新抛出该异常。当方法的调用者无力处理该异常的时候，应该继续抛出，

而不是囫囵吞枣一般在catch块中打印一下堆栈信息做个勉强处理。下面给出一个简单例子，

看看如何使用这两个关键字：

Java代码

public static void test3() throws Exception{

//抛出一个检查异常

throw new Exception("方法test3中的Exception");

}

public static void test3() throws Exception{

//抛出一个检查异常

throw new Exception("方法test3中的Exception");

}

4、 Throwable类中的常用方法

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

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

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

J2EE项目中的异常处理

目前,J2ee项目一般都会从逻辑上分为多层。比较经典的分为三层：表示层，业务层，集成层(包括数据库访问和外部系统的访问)。

J2ee项目有着其复杂性，J2ee项目的异常处理需要特别注意几个问题。

在分布式应用时，我们会遇到许多checked异常。所有RMI调用（包括EJB远程接口调用）都会抛出java.rmi.RemoteException;同时RemoteException是checked异常，当我们在业务系统中进行远程调用时，我们都需要编写大量的代码来处理这些checked异常。而一旦发生RemoteException这些checked异常对系统是非常严重的，几乎没有任何进行重试的可能。也就是说，当出现RemoteException这些可怕的checked异常，我们没有任何重试的必要性，却必须要编写大量的try…catch代码去处理它。一般我们都是在最底层进行RMI调用，只要有一个RMI调用，所有上层的接口都会要求抛出RemoteException异常。因为我们处理RemoteException的方式就是把它继续往上抛。这样一来就破坏了我们业务接口。RemoteException这些J2EE系统级的异常严重的影响了我们的业务接口。我们对系统进行分层的目的就是减少系统之间的依赖，每一层的技术改变不至于影响到其它层。

java 代码

public class UserSoaImpl implements UserSoa{

public UserInfo getUserInfo(String userId)throws RemoteException{

//远程方法调用.

}

}

public interface UserManager{

public UserInfo getUserInfo(Stirng userId)throws RemoteException;

}

同样JDBC访问都会抛出SQLException的checked异常。

为了避免系统级的checked异常对业务系统的深度侵入，我们可以为业务方法定义一个业务系统自己的异常。针对像SQLException,RemoteException这些非常严重的异常，我们可以新定义一个unChecked的异常，然后把SQLException，RemoteException封装成unChecked异常后抛出。

如果这个系统级的异常是要交由上一级调用者处理的，可以新定义一个checked的业务异常，然后把系统级的异常封存装成业务级的异常后再抛出。

一般地，我们需要定义一个unChecked异常，让集成层接口的所有方法都声明抛出这unChecked异常。

java 代码

public DataAccessException extends RuntimeException{

……

}

public interface UserDao{

public String getPassword(String userId)throws DataAccessException;

}

public class UserDaoImpl implements UserDAO{

public String getPassword(String userId)throws DataAccessException{

String sql = “select password from userInfo where userId= ‘”+userId+”’”;

try{

…

//JDBC调用

s.executeQuery(sql);

…

}catch(SQLException ex){

throw new DataAccessException(“数据库查询失败”+sql,ex);

}

}

}

定义一个checked的业务异常，让业务层的接口的所有方法都声明抛出Checked异常.

java 代码

public class BusinessException extends Exception{

…..

}

public interface UserManager{

public Userinfo copyUserInfo(Userinfo user)throws BusinessException{

Userinfo newUser = null;

try{

newUser = (Userinfo)user.clone();

}catch(CloneNotSupportedException ex){

throw new BusinessException(“不支持clone方法:”+Userinfo.class.getName(),ex);

}

}

}

J2ee表示层应该是一个很薄的层，主要的功能为：获得页面请求，把页面的参数组装成POJO对象，调用相应的业务方法，然后进行页面转发，把相应的业务数据呈现给页面。表示层需要注意一个问题，表示层需要对数据的合法性进行校验，比如某些录入域不能为空，字符长度校验等。

J2ee从页面所有传给后台的参数都是字符型的，如果要求输入数值或日期类型的参数时，必须把字符值转换为相应的数值或日期值。

如果表示层代码校验参数不合法时，应该返回到原始页面，让用户重新录入数据，并提示相关的错误信息。

通常把一个从页面传来的参数转换为数值，我们可以看到这样的代码

java 代码

ModeAndView handleRequest(HttpServletRequest request,HttpServletResponse response)throws Exception{

String ageStr = request.getParameter(“age”);

int age = Integer.parse(ageStr);

…………

String birthDayStr = request.getParameter(“birthDay”);

SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);

Date birthDay = format.parse(birthDayStr);

}

上面的代码应该经常见到，但是当用户从页面录入一个不能转换为整型的字符或一个错误的日期值。

Integer.parse()方法被抛出一个NumberFormatException的unChecked异常。但是这个异常绝对不是一个致命的异常,一般当用户在页面的录入域录入的值不合法时，我们应该提示用户进行重新录入。但是一旦抛出unchecked异常，就没有重试的机会了。像这样的代码造成大量的异常信息显示到页面。使我们的系统看起来非常的脆弱。

同样，SimpleDateFormat.parse()方法也会抛出ParseException的unChecked异常。

这种情况我们都应该捕获这些unChecked异常，并给提示用户重新录入。

java 代码

ModeAndView handleRequest(HttpServletRequest request,HttpServletResponse response)throws Exception{

String ageStr = request.getParameter(“age”);

String birthDayStr = request.getParameter(“birthDay”);

int age = 0;

Date birthDay = null;

try{

age=Integer.parse(ageStr);

}catch(NumberFormatException ex){

error.reject(“age”,”不是合法的整数值”);

}

…………

try{

SimpleDateFormat format = new SimpleDateFormat(“MM/dd/yyyy”);

birthDay = format.parse(birthDayStr);

}catch(ParseException ex){

error.reject(“birthDay”,”不是合法的日期，请录入’MM/dd/yyy’格式的日期”);

}

}

在表示层一定要弄清楚调用方法的是否会抛出unChecked异常，什么情况下会抛出这些异常，并作出正确的处理。

在表示层调用系统的业务方法，一般情况下是无需要捕获异常的。如果调用的业务方法抛出的异常相当于第二个返回值时，在这种情况下是需要捕获

Java 异常处理的原则和忌讳

Java 异常处理的原则

能处理就早处理

抛出不去还不能处理的就想法消化掉或者转换为RuntimeException处理。

因为对于一个应用系统来说，抛出大量异常是有问题的，应该从程序开发角度尽可能的控制异常发生的可能。

对于检查异常

如果不能行之有效的处理，还不如转换为RuntimeException抛出。

这样也让上层的代码有选择的余地――可处理也可不处理。

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

尽可能的处理异常

要尽可能的处理异常，如果条件确实不允许，无法在自己的代码中完成处理，就考虑声明异常。如果人为避免在代码中处理异常，仅作声明，则是一种错误和依赖的实践。

具体问题具体解决

异常的部分优点在于能为不同类型的问题提供不同的处理操作。有效异常处理的关键是识别特定故障场景，并开发解决此场景的特定相应行为。为了充分利用异常处理能力，需要为特定类型的问题构建特定的处理器块。

记录可能影响应用程序运行的异常

至少要采取一些永久的方式，记录下可能影响应用程序操作的异常。理想情况下，当然是在第一时间解决引发异常的基本问题。不过，无论采用哪种处理操作，一般总应记录下潜在的关键问题。别看这个操作很简单，但它可以帮助您用很少的时间来跟踪应用程序中复杂问题的起因。

根据情形将异常转化为业务上下文

若要通知一个应用程序特有的问题，有必要将应用程序转换为不同形式。若用业务特定状态表示异常，则代码更易维护。从某种意义上讲，无论何时将异常传到不同上下文（即另一技术层），都应将异常转换为对新上下文有意义的形式。

Java 异常处理的忌讳

一般不要忽略异常

在异常处理块中，一项最危险的举动是“不加通告”地处理异常。如下例所示：

1 try{

2 Class.forName("business.domain.Customer");

3 }

4 catch (ClassNotFoundException exc){}

经常能够在代码块中看到类似的代码块。有人总喜欢在编写代码时简单快速地编写空处理器块，并“自我安慰地”宣称准备在“后期”添加恢复代码，但这个“后期”变成了“无期”。

这种做法有什么坏处？如果异常对应用程序的其他部分确实没有任何负面影响，这未尝不可。但事实往往并非如此，异常会扰乱应用程序的状态。此时，这样的代码无异于掩耳盗铃。

这种做法若影响较轻，则应用程序可能出现怪异行为。例如，应用程序设置的一个值不见了， 或 GUI 失效。若问题严重，则应用程序可能会出现重大问题，因为异常未记录原始故障点，难以处理，如重复的 NullPointerExceptions。

如果采取措施，记录了捕获的异常，则不可能遇到这个问题。实际上，除非确认异常对代码其余部分绝无影响，至少也要作记录。进一步讲，永远不要忽略问题；否则，风险很大，在后期会引发难以预料的后果。

不要使用覆盖式异常处理块

另一个危险的处理是覆盖式处理器（blanket handler）。该代码的基本结构如下：

1 try{

2 // …

3 }

4 catch(Exception e){

5 // …

6 }

使用覆盖式异常处理块有两个前提之一：

1. 代码中只有一类问题。

这可能正确，但即便如此，也不应使用覆盖式异常处理，捕获更具体的异常形式有利物弊。

2. 单个恢复操作始终适用。

这几乎绝对错误。几乎没有哪个方法能放之四海而皆准，能应对出现的任何问题。

分析下这样编写代码将发生的情况。只要方法不断抛出预期的异常集，则一切正常。但是，如果抛出了未预料到的异常，则无法看到要采取的操作。当覆盖式处理器对新异常类执行千篇一律的任务时，只能间接看到异常的处理结果。如果代码没有打印或记录语句，则根本看不到结果。

更糟糕的是，当代码发生变化时，覆盖式处理器将继续作用于所有新异常类型，并以相同方式处理所有类型。

一般不要把特定的异常转化为更通用的异常

将特定的异常转换为更通用异常时一种错误做法。一般而言，这将取消异常起初抛出时产生的上下文，在将异常传到系统的其他位置时，将更难处理。见下例：

1 try{

2 // Error-prone code

3 }

4 catch(IOException e){

5 String msg = "If you didn ’ t have a problem before,you do now!";

6 throw new Exception(msg);

7 }

因为没有原始异常的信息，所以处理器块无法确定问题的起因，也不知道如何更正问题。

不要处理能够避免的异常

对于有些异常类型，实际上根本不必处理。通常运行时异常属于此类范畴。在处理空指针或者数据索引等问题时，不必求助于异常处理。

异常的转译与异常链

异常转译的原理

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

在Java中有个概念就是异常原因，异常原因导致当前抛出异常的那个异常对象，

几乎所有带异常原因的异常构造方法都使用Throwable类型做参数，这也就为异常的转译提供了直接的支持，

因为任何形式的异常和错误都是Throwable的子类。比如将SQLException转换为另外一个新的异常DAOException，

可以这么写：

先自定义一个异常DAOException：

Java代码

public class DAOException extends RuntimeException {

/(省略了部分代码)

public DAOException(String message, Throwable cause) {

super(message, cause);

}

public class DAOException extends RuntimeException {

//(省略了部分代码)

public DAOException(String message, Throwable cause) {

super(message, cause);

}

}

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

Java代码

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

DAOException daoEx = 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：目的还是一样的。把所有的异常和错误转译为不检查异常，

这样可以让代码更为简洁，还有利于对错误和异常信息的统一处理。

异常链

异常链顾名思义就是将异常发生的原因一个传一个串起来，即把底层的异常信息传给上层，这样逐层抛出。

Java API文档中给出了一个简单的模型：

Java代码

try {

lowLevelOp();

} catch (LowLevelException le) {

throw (HighLevelException)

new HighLevelException().initCause(le);

}

当程序捕获到了一个底层异常le，在处理部分选择了继续抛出一个更高级别的新异常给此方法的调用者。

这样异常的原因就会逐层传递。这样，位于高层的异常递归调用getCause()方法，就可以遍历各层的异常原因。

这就是Java异常链的原理。异常链的实际应用很少，发生异常时候逐层上抛不是个好注意，

上层拿到这些异常又能奈之何？而且异常逐层上抛会消耗大量资源，

因为要保存一个完整的异常链信息.

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

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

以处理系统运行过程中的所有异常。

基于这种观点，可以设计一个应用系统的异常比如叫做AppException。并且对用户来说，

这些异常都是运行应用系统运行时发生的，因此AppException应该继承RuntimeException，

这样系统中所有的其他异常都转译为AppException，当异常发生的时候，前端接收到AppExcetpion并做统一的处理。

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



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

在这个设计图中，AppRuntimeException是系统异常的基类，对外只抛出这个异常，

这个异常可以由前端（客户端）接收处理，当异常发生时，客户端的相关组件捕获并处理这些异常， 将"友好"的信息展示给客户。

在AppRuntimeException下层，有各种各样的异常和错误，最终都转译为AppRuntimeException，

AppRuntimeException下面还可以设计一些别的子类异常，比如AppDAOException、OtherException等，

这些都根据实际需要灵活处理。

在往下就是如何将捕获的原始异常比如SQLException、HibernateException转换为更高级一点AppDAOException。

有关异常框架设计这方面公认比较好的就是Spring，Spring中的所有异常都可以用org.springframework.core.NestedRuntimeException来表示，并且该基类继承的是RuntimeException。

Spring框架很庞大，因此设计了很多NestedRuntimeException的子类，还有异常转换的工具，

这些都是非常优秀的设计思想。

异常处理总结

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

1、 异常是程序运行过程过程出现的错误，在Java中用类来描述，用对象来表示具体的异常。

Java将其区分为Error与Exception，Error是程序无力处理的错误，Exception是程序可以处理的错误。

异常处理是为了程序的健壮性。

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

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

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

5、 对于一个应用系统，设计一套良好的异常处理体系很重要。这一点在系统设计的时候就应该考虑到。对异常处理的重视会是您开发出的代码更健壮，更稳定。本文系统的阐述了 Java 异常处理的原理和方法。能帮助读者更加清楚的理解 Java 异常处理机制，在开发代码时更加灵活的使用它。