Java异常处理的最佳实践归纳.docVIP

异常处理的关键就在于知道何时处理异常以及如何使用异常。这篇文章，我会提到一些最佳的异常处理方法。我也会总结 checked exception 的用法。 　　我们程序员都想写出高质量的代码来解决问题。但是，异常有时会给我们的代码带来副作用。没有人喜欢副作用，所以我们很快找到了方法来改善它们。我看见过许多聪明的程序员这样来处理异常: 1 2 3 4 5 6 7 public void consumeAndForgetAllExceptions (){ try { ...some code that throws exceptions } catch (Exception ex){ ex.printStacktrace (); } } 　　上面的代码有什么错误？ 　　当异常被抛出后，正常的程序执行过程中断，控制权交给 catch 段，catch 段会 catch 异常，然后抑制异常的进一步扩大。然后接着 catch 段之后程序继续执行，好像什么都没发生过一样。 　　下面的代码呢？ 1 2 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 异常等级实例 　　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 代码段，或者仅仅抛