下面的文章是我译自Rod Johnson的"J2EE Design and Developement", 解答了我长久以
来的一个疑问， 希望对大家有用。
异常处理 - Checked还是Unchecked Java明确区分两种类型的异常.
那些扩展了java.lang.Exception的异常称为checked exceptions,
编译器要求这些异常必须被捕获或者重新抛出.
那些扩展了java.lang.RuntimeException的异常称为unchecked exceptions,
它们不是必须捕获的. 当然, 也可以捕获这些异常并相应地扩展调用栈,
就像通常对checked exceptions做的那样. Java是唯一的支持checked
exceptions的主流语言, 而所有的C++和C#异常都相当于Java的unchecked exceptions.
首先, 让我们考虑一下Java中接收异常时的行为. 在Sun提供的Java教程中提到了这一点,
参见 [url]http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html.[/url]
其中的建议是在代码中使用checked exceptions:
"因为Java语言不要求一个方法捕获运行时异常或定义抛出何种运行时异常, 对程序员来说,

仅抛出运行时异常或使所有的自定义异常都从RuntimeException继承就显得很有诱惑力.
这两种编程的便捷方法都使得程序员可以这样写Java代码,
免于Java编译器的唠唠叨叨的错误提示, 也不用定义或捕获任何异常. 这看上去很方便,
但是这种故意回避Java语言关于捕获异常和定义异常规范的要求的做法,
可能会对使用你的Java类的其他程序员造成问题.
Checked exceptions表示了关于一个操作的一些有用的信息, 这项操作调用者无法控制,
但是调用者又需要知道这些信息. 比如, 文件系统可能已满, 或者远端关闭了连接,
又或者访问授权不足以执行这项操作.
那么, 如果仅仅因为你不想定义异常规范就抛出一个RuntimeException或其子类,
你能得到什么呢? 很简单, 你能够抛出一个没有明确定义的异常. 或者说,
这是一种避免文档化一个方法能抛出的每一项异常的方法. 这好吗?
也许只比根本不文档化方法的语义好一点吧. 所以答案就是几乎从来都不应使用unchecked
exceptions."
总结一下, 正统的Java做法是: 使用checked exceptions,
而运行时异常(RuntimeException)预示编程上的错误.
我曾经也同意这种观点. 但是, 在书写了成千上万个异常捕获代码块之后,
我得出这样的结论, 这种理论在实践中并不总是可行的. 我并不是唯一这么想的人.

既然在这一点上慢慢形成我自己的观点, 我注意到Bruce Eckel, 他是经典的Thinking in
Java的作者, 也改变了他的观点. 现在Eckel提倡使用运行时异常, 并且怀疑checked
exceptions是否只是一种不成功的试验, 应该从Java中抛弃.
参见 [url]http://www.mindview.net/Etc/Discussions/CheckedExceptions.[/url]
Eckel声称观察表明, 当一个程序员关注一小段代码时, checked
exceptions看上去是一种漂亮的想法, 可以避免很多错误. 但是,
在大规模的代码中情况正好相反.
可以参考 [url]http://www.octopull.demon.co.uk/java/ExceptionalJava.html[/url]上Alan
Griffiths的"Exceptional Java", 这是另外一个关于checked
exceptions引起的问题的研究.
使用checked exceptions引起以下一些问题:
1. 代码膨胀. 程序员必须书写代码捕获并忽略那些他们并不能合理地加以处理的异常,
他们将变得很泄气. 这是一种糟糕的编程实践,
经验表明它们发生得比我们想象的更为频繁.
即使是一个好的程序员也会偶尔忘记正确地将异常嵌套, 这意味着完整的调用栈将丢失,
异常中包含的信息就不再那么有用.
2. 代码的可读性降低. 在例程中捕获那些不能合理加以处理的异常并马上重新抛出它们,
使得很难找到那些真正做一些事情的代码.
Java的正统观点认为这一点只困扰那些懒惰的程序员, 我们应该简单地忽略这个问题.
然而, 这种观点忽略了事实. 例如, 设计Java核心库的人显然清楚地考虑过这个问题.
想象一下, 如果象java.util.Iterator这样的界面抛出checked
exceptions而不是unchecked exceptions, 那么使用它们将是一场噩梦. JDO
API是另外一个来自Sun自己的API的例子, 它使用unchecked exceptions. 相反,
JDBC使用checked exceptions, 使用起来就很笨重.
3. 没完没了地包装异常. 一个checked exceptions必须被捕获,
或者声明在可能遇到它们的那些方法的异常规范中. 这就造成一种选择,
可以重新抛出异常, 也可以将一个低级别的异常包装在一个新的高级别异常中,
然后重新抛出. 如果我们加入了一些有用的信息, 包装并重新抛出异常是很值得的. 但是,
如果原来的异常是不可恢复的, 包装它们就毫无价值. 如果使用unchecked exceptions,
在这种情况下将引起一个自动的栈回绕, 而使用checked exceptions,
我们无非做了一个等价的手工栈回绕,
并且在调用栈路径上的每一个方法中都要添加一些额外的毫无意义的代码,
只是为了包装异常. 主要是这个原因才促使我重新思考自己关于异常处理的态度.
4. 脆弱的原型声明. 如果很多代码都使用了某个界面,
那么要声明一条额外的异常规范就会导致修改大量代码.
5. 定义接口时, Checked exceptions并不总是工作得那么良好.
考虑Java教程中文件系统满的例子. 如果我们谈论的是一个使用文件系统的类,
这个例子没有问题. 如果我们处理的是一个仅仅承诺在某处(也许是数据库)存储数据的类,
情况又怎样呢? 我们肯定不想在这个类的接口中硬编码进对Java I/O API的依赖,
因为这个接口很可能有许多不同的实现. 若使用checked exceptions,
我们必须为这个接口创建一个新的存储介质无关的异常类型,
并且将文件系统异常包装其中. 这样做是否值得依赖于发生的异常是不是可恢复的.
如果不可恢复, 我们又一次做了无用功.
很多这些问题归结于这样一个问题: 我们捕获了一个无法处理的异常,
被迫重新抛出一个包装过的异常. 这很讨厌, 很容易引起错误(因为很容易丢失调用栈),
并且没有用. 此时使用unchecked exceptions更佳. Unchecked
exceptions会引发自动的栈回绕, 而且也是在发生致命错误时的正确行为.
我相信checked exceptions在一种情况下是有用的, 这一点不象Eckel,
也使我的观点不是那么的不正统. 当异常等同于方法的另外一个返回值时, 应使用checked
exceptions, 更棒的是语言将帮助强制必须检查这一返回值.
我只是认为通常的Java约定过分强调了这一点.
"Checked exceptions比许多老的语言中使用的错误返回值要好得多.
程序员迟早将不再检查错误返回值, 能使用编译器强制正确的错误处理真是太好了.
这样的checked exceptions应该象参数和返回值那样是API的一部分."
然而, 我不建议使用checked exceptions, 除非调用者能处理它们. Checked
exceptions尤其不应用来标示发生了一些致命错误, 这些错误不应由调用者来处理.
"如果调用者代码能做一些有意义的事情, 使用checked exceptions. 如果异常是致命的,
或者调用者不能通过捕获异常而有所收获, 使用unchecked exceptions.
记住你可以依赖于一个J2EE容器来捕获unchecked exceptions并记录它们."
以下是选择checked exceptions还是unchecked exceptions的指南:
问题 例子 肯定回答时的建议
--------------------------------------------------所有调用者都应处理 定义和使用checked
这个问题吗? 异常是 exceptions, 以利用
否只是函数的另外一 Java提供的编译时支持
个返回值?
--------------------------------------------------是否只有少数调用者 JDO异常 扩展RuntimeException.
需要处理这个问题? 这使得调用者可以捕获
异常, 但不强制所有调
用者都这么做
--------------------------------------------------是否发生了致命错误? 扩展RuntimeException.
错误是不可恢复的吗?
--------------------------------------------------还不清楚? 扩展RuntimeException.
将可能抛出的异常都写
进文档, 以便调用者决
定是否捕获和捕获哪些
异常
--------------------------------------------------在包一级做一个决定, 决定每个包如何使用checked和unchecked exceptions.
将使用unchecked exceptions的决定写进文档, 因为很多程序员还不习惯它.

使用unchecked exceptions的唯一危险是没有正确地写文档. 使用unchecked
exceptions时, 一定要将所有可能的异常写进文档, 让调用者选择是否捕获异常.
理想的情况下, 编译器应该强制将所有的异常写进Javadoc.
当分配JDBC连接这样的在所有情况下都应释放的资源时, 不管你是否需要捕获异常,
切记使用一个finalize块以保证正确的清除. 记住即使没有catch块,
仍然可以使用finalize块.
未捕获的运行时异常将杀死执行的线程, 有时这成为避免使用运行时异常的一个理由.
在一些情况下这是一个合理的论据, 但是J2EE应用中这通常不是一个问题,
因为我们极少控制线程, 而是让应用服务器来做这个.
应用服务器将捕获和处理那些在应用代码中没有捕获的运行时异常,
而不会让这些异常挂起整个Java虚拟机.
在EJB容器中发生的一个未捕获的运行时异常将导致EJB容器抛弃当前的EJB实例.
如果发生的错误是致命的, 这通常没什么不对.
说到底, 使用checked exception还是unchecked exception是一个观点的问题.
不光将采用的方式写进文档很重要, 尊重其他人的方法也很重要.
虽然我倾向于使用unchecked exception, 当维护或修改其他喜欢只使用checked
exception的程序员的代码时, 我将采用他们的方法.

异常处理的良好实践方法
无论使用checked exceptions还是unchecked exceptions, 我们总需要理异常嵌套的问题.
通常这发生在我们被迫捕获一个我们不能处理的异常, 而是重新抛出它们时.
这意味着我们必须将原始的嵌套的异常包装在一个新的异常中.
有一些标准的异常, 比如javax.servlet.ServletException, 提供了这样的包装功能.
在我们自己的应用的异常之中, 我们需要定义或使用自定义的异常父类,
这些父类有一个以其原始异常为参数的构造函数,
并且重载了printStackTrace()方法来显示完整的调用栈, 包括原始异常的调用栈在内.
通常我们需要两个这样的父类, checked exceptions和unchecked exceptions各一个.
(在JDK 1.4中不需要这么做, 因为它支持所有异常的嵌套.)
在本书的示例代码中,
这两个类分别是com.interface21.core.NestedCheckedException和com.interface21.core.
NestedRuntimeException.
除了分别继承自java.lang.Exception和java.lang.RuntimeException, 它们没什么不同.
这两个类都是抽象类, 它们的子类才有意义. NestedRuntimeException的定义如下:
package com.interface21.core;
import java.io.PrintStream;
import java.io.PrintWriter;

public abstract class NestedRuntimeException extends RuntimeException {
private Throwable rootCause;
public NestedRuntimeException(String s) {
super(s);
}
public NestedRuntimeException(String s, Throwable ex) {
super(s);
rootCause = ex;
}
public Throwable getRootCause() {
return rootCause;
}
public String getMessage() {
if (rootCause == null) {
return super.getMessage();
} else {
return super.getMessage() + "; nested exception is: nt" +
rootCause.toString();
}
}
public void printStackTrace(PrintStream ps) {
if (rootCause == null) {
super.printStackTrace(ps);
} else {
ps.println(this);
rootCause.printStackTrace(ps);
}
}
public void printStackTrace(PrintWriter pw) {
if (rootCause == null) {
super.printStackTrace(pw);
} else {
pw.println(this);
rootCause.printStackTrace(pw);
}
}
public void printStackTrace() {
printStackTrace(System.err);
}
}

Java 1.4在异常处理领域引进了受欢迎的改进. 不再需要写链式异常,
同时那些已经存在的象上面那样的代码工作起来也没有问题.
java.lang.Throwable和java.lang.Exception都有了新的构造函数, 支持异常的嵌套,
并且java.lang.Throwable新增了一个方法void initCause(Throwable
t)使得即使异常构造之后仍可以定义一个根异常.
这个方法应该只在构造函数没有定义嵌套异常的情况下被调用一次.
Java 1.4相关的异常应该实现一个以嵌套异常为参数的构造函数,
它再调用新的异常构造函数.
这意味着我们总是可以象下面那样在一行代码中创建和抛出异常:
catch (RootCauseException ex) {
throw new MyJava14Exception("Detailed message", ex);
}
如果异常没有提供这样的构造函数, 我们需要使用稍多一点的代码, 象这样:
catch (RootCauseException ex) {
MyJava13Exception mex = new MyJava13Exception("Detailed message");
mex.initCause(ex);
throw mex;
}
当使用象上面讨论的NestedRuntimeException那样的可嵌套异常时,
记得遵循它们自己的约定, 而不是Java 1.4那样的预定, 这样才能正常工作.
J2EE中的异常
当涉及J2EE应用时, 有几个特殊的问题需要考虑.
分布式应用将遇到许多checked exceptions. 这部分是因为在那些Java的早期历史中,
Sun有意这么做, 使得必须明确地使用远程调用. 所有的RMI调用,
包括那些EJB远程接口调用, 都抛出java.rmi.RemoteException,
这使得不可能做到本地调用和远程调用的透明. 这种决定大概是正确的,
因为本地调用和远程调用的透明性是很危险的, 特别是对性能. 但是,
这导致着我们经常书写代码来处理checked exceptions,
而这些异常仅仅意味着发生了致命的不值得重试的异常.
在servlets和JSP页面中,
从J2EE系统级异常如java.rmi.RemoteException保护接口代码是很重要的.
许多程序员没有认识到这一点, 这导致很不幸的后果,
比如造成对系统框架层不必要的依赖和失去重试一些操作的机会,
这些操作本应该在更低的层次上已经重试过了. 在那些认识到这些问题的程序员中间,
我看到两种策略:
1. 允许界面部分忽略这样的异常. 比如,
在所有处理呼入的WEB页请求的类的父类这样较高的层次上捕获异常,

这就允许子类在某个具有保护属性的抽象成员函数中抛出一类异常.
2. 当业务逻辑而非远程过程调用引起异常时, 不管是checked还是unchecked的,
使用客户端方法来取消和远端系统的通讯并抛出异常.
这就是说客户端方法不应该模拟远端组件的接口,
远端接口总是抛出java.rmi.RemoteException. 这种方法称为Business delegate J2EE
pattern, 是核心J2EE模式的一种.