异常处理的最佳实践

标签: IT技术 程序员 java 异常 | 发表时间:2012-05-14 03:23 | 作者:唐小娟
出处:http://blog.jobbole.com

译者注:这是一篇2003年的文章,因为时间久远,可能有些观点已经过时,但里面讨论的大部分方法如今仍能适用。如若有其他好的错误处理的方法,欢迎留言。

异常处理的关键就在于知道何时处理异常以及如何使用异常。这篇文章,我会提到一些最佳的异常处理方法。我也会总结checked exception的用法。

我们 程序员都想写出高质量的代码来解决问题。但是,异常有时会给我们的代码带来副作用。没有人喜欢副作用,所以我们很快找到了方法来改善它们。我看见过许多聪明的程序员这样来处理异常:

public void consumeAndForgetAllExceptions(){
    try {
        ...some code that throws exceptions
    } catch (Exception ex){
        ex.printStacktrace();
    }
}

上面的代码有什么错误?

当异常被抛出后,正常的程序执行过程中断,控制权交给catch段,catch段会catch 异常,然后抑制异常的进一步扩大。然后接着catch段之后程序继续执行,好像什么都没发生过一样。

下面的代码呢?

public void someMethod() throws Exception{
}

这个方法内没有代码,是个空方法。一个空方法怎么能抛出异常呢?Java并没有说不让这么做。最近,我遇到过类似的代码,方法抛出了异常,而其中的代码实际上并不产生那个异常。当我问这个程序员为何要这么做,他回答道“我知道,虽然这样做破坏了API,但我习惯这么做,而且这样也可行。”

C++社区用了许多年才确定如何使用异常机制。这个争论刚刚在Java社区展开。我见到一些Java程序员正在和异常进行顽强抗争。如果用法不当的话,会拖慢程序,因为创建、抛出和接住异常都会占用内存。如果过多的使用异常的话,代码会变得很难阅读,对要使用API的程序员来说无疑会增加挫败感。我们知道挫败感会令我们写出很烂的代码。有的程序员会刻意回避这个问题,忽略异常或随意抛出异常,就像上面的两个例子一样。

异常的本质

广义的讲,抛出异常分三种不同的情况:

编程错误导致的异常:在这个类别里,异常的出现是由于代码的错误(譬如NullPointerException和IllegalArgumentException)。代码通常对编程错误没有什么对策。

客户端的错误导致的异常:客户端代码试图违背制定的规则,调用API不支持的资源。如果在异常中显示有效信息的话,客户端可以采取其他的补救方法。例如:解析一个格式不正确的XML文档时会抛出异常,异常中含有有效的信息。客户端可以利用这个有效信息来采取恢复的步骤。

资源错误导致的异常:当获取资源错误时引发的异常。例如,系统内存不足,或者网络连接失败。客户端对于资源错误的反应是视情况而定的。客户端可能一段时间之后重试或者仅仅记录失败然后将程序挂起

 

Java异常的类型

Java定义了两种异常

Checked exception: 继承自Exception类是checked exception。代码需要处理API抛出的checked exception,要么用catch语句,要么直接用throws语句抛出去。

Unchecked exception: 也称RuntimeException,它也是继承自Exception。但所有RuntimeException的子类都有个特点,就是代码不需要处理它们的异常也能通过编译,所以它们称作unchecked exception。

图1显示了NullpointerException的继承级别。

图1 异常等级实例 图1 异常等级实例

 

NullpointerException继承自RuntimeException,所以它是个unchecked exception。

我看到人们大量使用checked exception的,而很少看到unchecked exception的使用。近来,在Java社区里对checked exception和它的真正价值的争论愈演愈烈。这主要因为Java是第一个使用checked exception的主流面向对象语言。C++和C#都没有checked exception,所有的异常都是unchecked。

低层次抛出的checked exception对高层次来说,必须要catch或者throw它们。这样如果不能有效处理异常的话,checked exception就在API和代码之间造成了一直负担。程序员就开始写一些空的catch代码段,或者仅仅抛出异常,实际上,给客户端的触发者来说增加了负担。

Checked exception也被诟病破坏了封装性。看看下面的代码:

public List getAllAccounts() throws
    FileNotFoundException, SQLException{
    ...
}

getAllAccounts()抛出了两个checked exception。这个方法的调用者就必须处理这两个异常,尽管它也不知道在getAllAccounts中什么文件找不到以及什么数据库语句失败,也不知道该提供什么文件系统或者数据库的事务层逻辑。这样,异常处理就在方法调用者和方法之间形成了一个不恰当的紧耦合。

 

设计API的最佳实践

说了这么多,让我们来说说如何设计一个好的API,能够正确抛出异常的。

1. 当要确定是使用checked exception还是unchecked exception时,首先问问自己,当异常发生时客户端如何应对?

如果客户端可以从异常中采取行动进行恢复的,就使用checked exception,如果客户什么也做不了,就用unchecked exception。我指的是,不仅仅是记录异常,还要采取措施来恢复。

还有,我更喜欢unchecked exception,因为不需要强迫客户端API必须处理它们。它们会进一步扩散,直到你想catch它们,或者它们会继续扩散爆出。Java API有许多unchecked exception如NullPointerException, IllegalArgumentException和IllegalStateException。我更愿意用这些Java定义好的异常类,而非我们自己创建的异常类。它们使我们的代码易读,也避免代码消耗更多内存。

2. 保持封装性

不要将针对某特定实现的checked exception用到更高的层次中去。例如,不要让SQLException扩散到逻辑层去。因为逻辑层是不需要知道SQLException。你有两种选择:

- 如果你的客户端有应对措施的话,将SQLException转化成另一个checked exception。

- 如果你的客户端什么也做不了的话,将SQLException转化成一个unchecked exception。

但大部分情况是,客户端对SQLException无能为力。那请将SQLException转换成unchecked exception吧。来看下面的代码:

public void dataAccessCode(){
    try{
        ..some code that throws SQLException
    }catch(SQLException ex){
        ex.printStacktrace();
    }
}

上面的catch段仅仅抑制了异常,什么也没做。这是因为客户针对SQLException无计可施。何不使用下面的方法呢?

public void dataAccessCode(){
    try{
        ..some code that throws SQLException
    }catch(SQLException ex){
        throw new RuntimeException(ex);
    }
}

将SQLException转换成RuntimeException。如果SQLException发生时,catch语句抛出一个新的RuntimeException异常。正在执行的线程会挂起,异常爆出来。然而,我并没有破坏逻辑层,因为它不需要进行不必要的异常处理,尤其是它根本不知道怎么处理SQLException。如果catch语句需要知道异常发生的根源,我可以用getCause()方法,这个方法在JDK1.4中所有异常类中都有。

如果你确信逻辑层可以采取某些恢复措施来应对SQLException时,你可以将它转换成更有意义的checked exception。但我发现仅仅抛出RuntimeException,大部分时间里都管用。

3. 如果自定义的异常没有提供有用的信息的话,请不要创建它们。

下面的代码有什么错误?

public class DuplicateUsernameException
    extends Exception {}

它没有给出任何有效的信息,除了提供一个异常名字意外。不要忘了Java异常类就像其他的类一样,当你在其中增加方法时,你也可以调用这些方法来获得更多信息。

我们可以在DuplicateUsernameException中增加有效的方法,例如:

public class DuplicateUsernameException
    extends Exception {
    public DuplicateUsernameException
        (String username){....}
    public String requestedUsername(){...}
    public String[] availableNames(){...}
}

新版本的DuplicateUsernameException提供两个方法:requestedUsername()返回请求的姓名,availableNames()返回与请求姓名相类似的所有姓名的一个数组。客户端可以知道被请求的姓名已经不可用了,以及其他可用的姓名。如果你不想获得其他的信息,仅仅抛出一个标准的异常即可:

throw new Exception("Username already taken");

如果你认为客户端不会采取任何措施,仅仅只是写日志说明用户名已存在的话,抛出一个unchecked exception:

throw new RuntimeException("Username already taken");

另外,你甚至可以写一个判断用户名是否已经存在的方法。

还是要重复一遍,当客户端的API可以根据异常的信息采取有效措施的话,我们可以使用checked exception。但对于所有的编程错误,我更倾向于unchecked exception。它们让你的代码可读性更高。

4. 将异常文档化

你可以采用Javadoc’s @throws标签将你的API抛出的checked和unchecked exception都文档化。然而,我更喜欢写单元测试。单元测试可看作可执行的文档。无论你选择哪一种方式,都要让客户端使用你的API时清楚知道你的API抛出哪些异常。下面是针对IndexOutOfBoundsException的单元测试:

public void testIndexOutOfBoundsException() {
    ArrayList blankList = new ArrayList();
    try {
        blankList.get(10);
        fail("Should raise an IndexOutOfBoundsException");
    } catch (IndexOutOfBoundsException success) {}
}

当调用blankList.get(10)时,上面的代码会抛出IndexOutOfBoundsException。如果不是如此的话,fail(“Should raise an IndexOutOfBoundsException”)会显式的让测试失败。通过写单元测试,你不仅记录了异常如何运作,也让你的代码变得更健壮。

 

使用异常的最佳实践

下面的部分我们列出了客户端代码处理API抛出异常的一些最佳实现方法。

1. 记得释放资源

如果你正在用数据库或网络连接的资源,要记得释放它们。如果你使用的API仅仅使用unchecked exception,你应该用完后释放它们,使用try-final。

public void dataAccessCode(){
    Connection conn = null;
    try{
        conn = getConnection();
        ..some code that throws SQLException
    }catch(SQLException ex){
        ex.printStacktrace();
    } finally{
        DBUtil.closeConnection(conn);
    }
}

class DBUtil{
    public static void closeConnection
        (Connection conn){
        try{
            conn.close();
        } catch(SQLException ex){
            logger.error("Cannot close connection");
            throw new RuntimeException(ex);
        }
    }
}

DBUtil是一个关闭连接的工具类。最重要的部分在于finally,无论异常发不发生都会执行。在这个例子中,finally关闭了连接,如果关闭过程中有问题发生的话,会抛出一个RuntimeException。

2. 不要使用异常作控制流程之用

生成栈回溯是非常昂贵的,栈回溯的价值是在于调试。在流程控制中,栈回溯是应该避免的,因为客户端仅仅想知道如何继续。

下面的代码,一个自定义的异常MaximumCountReachedException,用来控制流程。

public void useExceptionsForFlowControl() {
    try {
        while (true) {
            increaseCount();
        }
    } catch (MaximumCountReachedException ex) {
    }
    //Continue execution
}

public void increaseCount()
    throws MaximumCountReachedException {
    if (count >= 5000)
        throw new MaximumCountReachedException();
}

useExceptionsForFlowControl()使用了一个无限的循环来递增计数器,直至异常被抛出。这样写不仅降低了代码的可读性,也让代码变得很慢。记住异常仅用在有异常发生的情况。

3. 不要忽略异常

当一个API方法抛出checked exception时,它是要试图告诉你你需要采取某些行动处理它。如果它对你来说没什么意义,不要犹豫,直接转换成unchecked exception抛出,千万不要仅仅用空的{}catch它,然后当没事发生一样忽略它。

4. 不要catch最高层次的exception

Unchecked exception是继承自RuntimeException类的,而RuntimeException继承自Exception。如果catch Exception的话,你也会catch RuntimeException。

try{
..
}catch(Exception ex){
}

上面的代码会忽略掉unchecked exception。

5. 仅记录exception一次

对同一个错误的栈回溯(stack trace)记录多次的话,会让程序员搞不清楚错误的原始来源。所以仅仅记录一次就够了。

总结

这里是我总结出的一些异常处理最佳实施方法。我并不想引起关于checked exception和unchecked exception的激烈争论。你可以根据你的需要来设计代码。我相信,随着时间的推移,我们会找到些更好的异常处理的方法的。

 

原文: onjava.com   编译: 伯乐在线 – 唐小娟

【如需转载,请标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

 

相关文章

相关 [异常处理 最佳实践] 推荐:

异常处理的最佳实践

- - 博客 - 伯乐在线
译者注:这是一篇2003年的文章,因为时间久远,可能有些观点已经过时,但里面讨论的大部分方法如今仍能适用. 如若有其他好的错误处理的方法,欢迎留言. 异常处理的关键就在于知道何时处理异常以及如何使用异常. 这篇文章,我会提到一些最佳的异常处理方法. 我也会总结checked exception的用法.

.NET中异常处理的最佳实践

- - 极客521 | 极客521
可信任的设备:摄像头、鼠标以及键盘. 不要抛出“new Exception()”. 不要将重要的异常信息存储在Message属性中. 每个线程要包含一个try/catch块. 不要只记录Exception.Message的值,还需要记录Exception.ToString(). 清理代码要放在finally块中.

Java 编程中关于异常处理的 10 个最佳实践

- - 博客 - 伯乐在线
英文原文: 10 Exception handling Best Practices in Java Programming 编译: oschina. 异常处理是书写 强健 Java应用的一个重要部分. 它是关乎每个应用的一个非功能性需求,是为了优雅的处理任何错误状况,比如资源不可访问,非法输入,空输入等等.

Oracle 异常处理

- - 编程语言 - ITeye博客
使用RAISE_APPLICATION_ERROR存储过程. ============================================================ */ --演示该存储过程 BEGIN. RAISE_APPLICATION_ERROR(-20000, 'Account past due.');-- explicitly raise exception END; --创建子程序 CREATE OR REPLACE PROCEDURE account_status (.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.

MongoDB最佳实践

- - NoSQLFan
将 MongoDB加入到我们的服务支持列表中,是整个团队年初工作计划中的首要任务. 但我们感觉如果先添加一项对NoSQL存储的支持,而不是先升级已支持的关系型数据库,可能对用户不太好,毕竟目前的用户都使用关系型数据库. 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做.

spring mvc 异常处理(转)

- - 编程语言 - ITeye博客
链接:http://gaojiewyh.iteye.com/blog/1297746 (附源码). 链接:http://zywang.iteye.com/blog/983801 . 链接:http://www.cnblogs.com/xguo/p/3163519.html . 链接:http://fuliang.iteye.com/blog/947191 .

Oracle异常处理概念

- - Oracle - 数据库 - ITeye博客
5.1.1 预定义的异常处理. 5.1.2 非预定义的异常处理. 5.1.3 用户自定义的异常处理. 5.1.4  用户定义的异常处理. 5.2.1 在执行部分引发异常错误. 5.2.2 在声明部分引发异常错误. 5.3 异常错误处理编程. 5.4  在 PL/SQL 中使用 SQLCODE, SQLERRM异常处理函数.

Java异常处理策略

- - 研发管理 - ITeye博客
任务与预先设定的规则不相符的情况都可以称之为异常. 但凡业务逻辑操作,都会划定一些边界或规则,但是往往事与愿违,总会有调皮鬼来挑战系统的健壮性. 用户并不都是知道潜规则的,比如用户的银行账户中只有100块钱,但是用户不查询就直接取200块. 码农有时候太过自信了,比如你在编写文件下载功能时忽略了文件有可能不存在这个分支流程.