n层结构的J2EE项目中的异常处理之二 转载

2．Checked 异常 还是 unChecked 异常？

Java异常分为两大类:checked 异常和unChecked 异常。所有继承java.lang.Exception 的异常都属于checked异常。所有继承java.lang.RuntimeException的异常都属于unChecked异常。

当一个方法去调用一个可能抛出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都表示用户无法恢复的异常，如无法获得数据库连接，不能打开文件等。虽然用户也可以像处理checked异常一样捕获unChecked异常。但是如果调用者并没有去捕获unChecked异常时，编译器并不会强制你那么做。

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

java 代码
String str = “123”;
int value = Integer.parseInt(str);

parseInt的方法签名为：
java 代码
public static int parseInt(String s) throws NumberFormatException
因为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异常和unChecked异常的详细讨论可以参考

Alan Griffiths?http://www.octopull.demon.co.uk/java/ExceptionalJava.html

Bruce Eckel?http://www.mindView.net/Etc/Disscussions/CheckedExceptions

《java Tutorial》 http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

使用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异常？并没有一个绝对的标准。但是笔者可以给出一些建议

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

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

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

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