Exception 处理之最佳实践

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=337891 存档链接: https://web.archive.org/web/20041109160618id_/http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=337891

静若处子 <<<毕业半年 | 主页 | 有可能志同道合的blog连接>>> Exception 处理之最佳实践 2004-08-10 原文： http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html “本文是 Exception 处理的一篇不错的文章，从 Java Exception 的概念介绍起，依次讲解了 Exception 的类型（ Checked/Unchecked ）， Exception 处理的最佳实现： 1．选择 Checked 还是 Unchecked 的几个经典依据 2． Exception 的封装问题 3．如无必要不要创建自己得 Exception 4．不要用 Exception 来作流程控制 5．不要轻易的忽略捕获的 Exception 6．不要简单地捕获顶层的 Exception ” ――选自 JAVADigest.Net 对原文的介绍 “ JAVADigest.Net 这个站点不知道大家是否经常上，就像它的名字一样，它让我们更加有效的消化 Java ，或者它就像个中转站一样，至少对我是这样的，有些好的可以说是非常经典的技术文章，我都是通过它第一次获得，更多的时候我是为了偷懒才上 JAVADigest.Net ，因为如果是近期比较经典的文章，它上边都有介绍文字和原文连接。” ――小插曲并非常荣幸地推荐 JAVADigest.Net 给你关于异常处理的一个问题就是要对何时（ when ）和如何（ how ）使用它们做到了然于心。在本文中我将介绍一些关于异常处理的最佳实践，同时我也会涉及到最近争论十分激烈的 checked Exception 的使用问题。作为开发员，我们都希望能写出解决问题并且是高质量的代码。不幸的是，一些副作用（ side effects ）伴随着异常在我们的代码中慢慢滋生。无庸置疑，没有人喜欢副作用（ side effects ） , 所以我们很快就用我们自己的方式来避免它，我曾经看到一些聪明的程序员用下面的方式来处理异常： public void consumeAndForgetAllExceptions(){ try { ...some code that throws exceptions } catch (Exception ex){ ex.printStacktrace(); } } 上边的代码有什么问题么？在回答以前让我们想想怎样才是正确的？是的，一旦程序碰到异常，它就该挂起程序而“做”点什么。那么上边的代码是这样子的么？看吧，它隐瞒了什么？它把所有的“苦水”往肚里咽（在控制台打印出异常信息），然后一切继续，从表面上看就像什么都没有发生过一样……，很显然，上边代码达到的效果并不是我们所期望的。后来又怎样？ public void someMethod() throws Exception{ } 上边的代码又有什么问题？很明显，上边的方法体是空的，它不实现任何的功能（没有一句代码），试问一个空方法体能抛出什么异常？当然 Java 并不阻止你这么干。最近，我也遇到类似的情景，方法声明会抛出异常，但是代码中并没有任何“机会”来“展示”异常。当我问开发员为什么要这样做的时候，他回答我说“我知道，它确实有点那个，但我以前就是这么干的并且它确实能为我工作。” 在 C++ 社区曾经花了数年实践来实践如何使用异常，关于此类的争论在 java 社区才刚刚开始。我曾经看到许多 Java 程序员针对使用异常的问题进行争论。如果对于异常处理不当的话，异常可以大大减慢应用程序的执行速度，因为它将消耗内存和 CPU 来创建、抛出并捕获异常。如果过分的依赖异常处理，代码对易读和易使用这两方面产生影响，以至于会让我们写出上边两处“糟糕”代码。异常原理大体上说，有三种不同的“情景”会导致异常的抛出： l 编程错误导致异常（ Exception due Programming errors ） : 这种情景下，异常往往处于编程错误（如： NullPointerException 或者 IllegalArgumentException ） , 这时异常一旦抛出，客户端将变得无能为力。 l 客户端代码错误导致异常（ Exception due client code errors ） : 说白点就是客户端试图调用 API 不允许的操作。 l 资源失败导致异常（ Exception due to resource failures ） : 如内存不足或网络连接失败导致出现异常等。这些异常的出现客户端可以采取相应的措施来恢复应用程序的继续运行。 Java 中异常的类型 Java 中定义了两类异常： l Checked exception: 这类异常都是 Exception 的子类 l Unchecked exception: 这类异常都是 RuntimeException 的子类，虽然 RuntimeException 同样也是 Exception 的子类，但是它们是特殊的，它们不能通过 client code 来试图解决，所以称为 Unchecked exception 举个例子，下图为 NullPointerException 的继承关系： Figure 1. Sample exception hierarchy 图中， NullPointerException 继承自 RuntimeException ，所以它是 Unchecked exception. 以往我都是应用 checked exception 多于 Unchecked exception ，最近，在 java 社区激起了一场关于 checked exception 和使用它们的价值的争论。这场争论起源于 JAVA 是第一个拥有 Checked exception 的主流 OO 语言这样一个事实，而 C++ 和 C# 都是根本没有 Checked exception ，它们所有的异常都是 unchecked 。一个 checked exception 强迫它的客户端可以抛出并捕获它，一旦客户端不能有效地处理这些被抛出的异常就会给程序的执行带来不期望的负担。 Checked exception 还可能带来封装泄漏，看下面的代码： public List getAllAccounts() throws FileNotFoundException, SQLException{ ... } 上边的方法抛出两个异常。客户端必须显示的对这两种异常进行捕获和处理即使是在完全不知道这种异常到底是因为文件还是数据库操作引起的情况下。因此，此时的异常处理将导致一种方法和调用之间不合适的耦合。接下来我会给出几种设计异常的最佳实践（ Best Practises for Designing the API ） 1．当要决定是采用 checked exception 还是 Unchecked exception 的时候，你要问自己一个问题，“如果这种异常一旦抛出，客户端会做怎样的补救？ ” [ 原文： When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"] 如果客户端可以通过其他的方法恢复异常，那么这种异常就是 checked exception ；如果客户端对出现的这种异常无能为力，那么这种异常就是 Unchecked exception ；从使用上讲，当异常出现的时候要做一些试图恢复它的动作而不要仅仅的打印它的信息，总来的来说，看下表： Client's reaction when exception happens Exception type Client code cannot do anything Make it an unchecked exception Client code will take some useful recovery action based on information in exception Make it a checked exception 此外，尽量使用 unchecked exception 来处理编程错误：因为 unchecked exception 不用使客户端代码显示的处理它们，它们自己会在出现的地方挂起程序并打印出异常信息。 Java API 中提供了丰富的 unchecked excetpion ，譬如： NullPointerException , IllegalArgumentException 和 IllegalStateException 等，因此我一般使用这些标准的异常类而不愿亲自创建新的异常类，这样使我的代码易于理解并避免的过多的消耗内存。 2．保护封装性（ Preserve encapsulation ）不要让你要抛出的 checked exception 升级到较高的层次。例如，不要让 SQLException 延伸到业务层。业务层并不需要（不关心？） SQLException 。你有两种方法来解决这种问题： l 转变 SQLException 为另外一个 checked exception ，如果客户端并不需要恢复这种异常的话； l 转变 SQLException 为一个 unchecked exception ，如果客户端对这种异常无能为力的话；多数情况下，客户端代码都是对 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 被抛出，那么程序将抛出 RuntimeException, 此时程序被挂起并返回客户端异常信息。如果你有足够的信心恢复它当 SQLException 被抛出的时候，那么你也可以把它转换为一个有意义的 checked exception, 但是我发现在大多时候抛出 RuntimeException 已经足够用了。 3．不要创建没有意义的异常（ Try not to create new custom exceptions if they do not have useful information for client code. ）看看下面的代码有什么问题？ public class DuplicateUsernameException extends Exception {} 它除了有一个“意义明确”的名字以外没有任何有用的信息了。不要忘记 Exception 跟其他的 Java 类一样，客户端可以调用其中的方法来得到更多的信息。我们可以为其添加一些必要的方法，如下： public class DuplicateUsernameException extends Exception { public DuplicateUsernameException (String username){....} public String requestedUsername(){...} public String[] availableNames(){...} } 在新的代码中有两个有用的方法： reqeuestedUsername(), 客户但可以通过它得到请求的名称； availableNames(), 客户端可以通过它得到一组有用的 usernames 。这样客户端在得到其返回的信息来明确自己的操作失败的原因。但是如果你不想添加更多的信息，那么你可以抛出一个标准的 Exception: throw new Exception("Username already taken"); 更甚的情况，如果你认为客户端并不想用过多的操作而仅仅想看到异常信息，你可以抛出一个 unchecked exception: throw new RuntimeException("Username already taken"); 另外，你可以提供一个方法来验证该 username 是否被占用。很有必要再重申一下， checked exception 应该让客户端从中得到丰富的信息。要想让你的代码更加易读，请倾向于用 unchecked excetpion 来处理程序中的错误（ Prefer unchecked exceptions for all programmatic errors ）。 4． Document exceptions. 你可以通过 Javadoc’s @throws 标签来说明（ document ）你的 API 中要抛出 checked exception 或者 unchecked exception 。然而，我更倾向于使用来单元测试来说明（ document ）异常。不管你采用哪中方式，你要让客户端代码知道你的 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" ) 显示说明该测试失败。通过书写测试异常的单元测试，你不但可以看到异常是怎样的工作的，而且你可以让你的代码变得越来越健壮。下面作者将介绍界中使用异常的最佳实践（ Best Practices for Using Exceptions ） 1．总是要做一些清理工作（ Always clean up after yourself ）如果你使用一些资源例如数据库连接或者网络连接，请记住要做一些清理工作（如关闭数据库连接或者网络连接），如果你的 API 抛出 Unchecked exception ，那么你要用 try-finally 来做必要的清理工作： 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 是一个工具类来关闭 Connection. 有必要的说的使用的 finally 的重要性是不管程序是否碰到异常，它都会被执行。在上边的例子中， finally 中关闭连接，如果在关闭连接的时候出现错误就抛出 RuntimeException. 2．不要使用异常来控制流程（ Never use exceptions for flow control ）下边代码中， MaximumCountReachedException 被用于控制流程： public void useExceptionsForFlowControl() { alex_chew 发表于 2004-08-10 15:37 引用Trackback(0) | 编辑 Comments 发表评论最近更新 oracle Export and Import ORACLE FAQ - PART 4 性能调整 ORACLE FAQ - PART 3 备份与恢复 ORACLE FAQ - PART 2 ORACLE架构体系 ORACLE FAQ - PART 1 SQL&PL/SQL 关于dbms_sql的使用 Oracle存储过程移植中的问题 oracle sequence使用 JDBC 连接各种数据库方法十一大假归来