如何建立知识框架体系 构建更好的异常处理框架

构建更好的异常处理框架  

　　企业应用程序在构建时常常对异常处理关注甚少 这会造成对低级异常（如 java rmi RemoteException 和 javax naming NamingException）的过度依赖 在 EJB 最佳实践的这篇专栏文章中 Brett McLaughlin 解释了为什么对异常处理投入一点关注就会给我们带来很大的帮助 并向您展示了两种简单技术 它们将帮助您正确地构建更健壮且有用的异常处理框架 　　　　在本系列先前的技巧文章中 异常处理不属于讨论的核心范围之内 但是 您可能会发现一点 那就是我们一直都回避来自 Web 层的低级异常 我们向客户机提供诸如 ApplicationException 和 InvalidDataException 之类的异常 而没有让 Web 层处理象 java rmi RemoteException 或 javax naming NamingException 这样的异常 　　　　远程和命名异常是系统级异常 而应用程序和非法数据异常是业务级异常 因为它们提交更适用的业务信息 当决定抛出何种类型的异常时 您应该总是首先考虑将要处理所报告异常的层 Web 层通常是由执行业务任务的最终用户驱动的 所以最好用它处理业务级异常 但是 在 EJB 层 您正在执行系统级任务 如使用 JNDI 或数据库 尽管这些任务最终将被合并到业务逻辑中 但是最好用诸如 RemoteException 之类的系统级异常来表示它们 　　　　理论上 您可以让所有 Web 层方法预期处理和响应单个应用程序异常 正如我们在先前的一些示例中所做的一样 但这种方法不适用于长时间运行 让您的委派方法抛出更具体的异常 这是一个好得多的异常处理方案 从根本上讲 这对接收客户机更有用 在这篇技巧文章中 我们将讨论两种技术 它们将有助于您创建信息更丰富 更具体的异常 而不会生成大量不必要的代码 　　　　 嵌套的异常　　在设计可靠的异常处理方案时 要考虑的第一件事情就是对所谓的低级或系统级异常进行抽象化 这些核心 Java 异常通常会报告网络流量中的错误 JNDI 或 RMI 问题 或者是应用程序中的其它技术问题 RemoteException EJBException 和 NamingException 是企业 Java 编程中低级异常的常见例子 　　　　这些异常完全没有任何意义 由 Web 层的客户机接收时尤其容易混淆 如果客户机调用 purchase() 并接收到 NamingException 那么它在解决这个异常时会一筹莫展 同时 应用程序代码可能需要访问这些异常中的信息 因此不能轻易地抛弃或忽略它们 　　　　答案是提供一类更有用的异常 它还包含低级异常 清单 演示了一个专为这一点设计的简单 ApplicationException 　　　　清单 嵌套的异常 package ibm;　　import java io PrintStream;　　import java io PrintWriter;　　public class ApplicationException extends Exception {　　/** A wrapped Throwable */　　protected Throwable cause;　　public ApplicationException() {　　super( Error occurred in application );　　}　　public ApplicationException(String message) {　　super(message);　　}　　public ApplicationException(String message Throwable cause) {　　super(message);　　this cause = cause;　　}　　// Created to match the JDK Throwable method 　　public Throwable initCause(Throwable cause) {　　this cause = cause;　　return cause;　　}　　public String getMessage() {　　// Get this exception s message 　　String msg = super getMessage();　　Throwable parent = this;　　Throwable child;　　// Look for nested exceptions 　　while((child = getNestedException(parent)) != null) {　　// Get the child s message 　　String msg = child getMessage();　　// If we found a message for the child exception 　　// we append it 　　if (msg != null) {　　if (msg != null) {　　msg += : + msg ;　　} else {　　msg = msg ;　　}　　}　　// Any nested ApplicationException will append its own　　// children so we need to break out of here 　　if (child instanceof ApplicationException) {　　break;　　}　　parent = child;　　}　　// Return the pleted message 　　return msg;　　}　　public void printStackTrace() {　　// Print the stack trace for this exception 　　super printStackTrace();　　Throwable parent = this;　　Throwable child;　　// Print the stack trace for each nested exception 　　while((child = getNestedException(parent)) != null) {　　if (child != null) {　　System err print( Caused by: );　　child printStackTrace();　　if (child instanceof ApplicationException) {　　break;　　}　　parent = child;　　}　　}　　}　　public void printStackTrace(PrintStream s) {　　// Print the stack trace for this exception 　　super printStackTrace(s);　　Throwable parent = this;　　Throwable child;　　// Print the stack trace for each nested exception 　　while((child = getNestedException(parent)) != null) {　　if (child != null) {　　s print( Caused by: );　　child printStackTrace(s);　　if (child instanceof ApplicationException) {　　break;　　}　　parent = child;　　}　　}　　}　　public void printStackTrace(PrintWriter w) {　　// Print the stack trace for this exception 　　super printStackTrace(w);　　Throwable parent = this;　　Throwable child;　　// Print the stack trace for each nested exception 　　while((child = getNestedException(parent)) != null) {　　if (child != null) {　　w print( Caused by: );　　child printStackTrace(w);　　if (child instanceof ApplicationException) {　　break;　　}　　parent = child;　　}　　}　　}　　public Throwable getCause() {　　return cause;　　}　　}　　　　清单 中的代码很简单 我们已经简单地将多个异常 串 在一起 以创建单个 嵌套的异常 但是 真正的好处在于将这种技术作为出发点 以创建特定于应用程序的异常层次结构 异常层次结构将允许 EJB 客户机既接收特定于业务的异常也接收特定于系统的信息 而不需要编写大量额外代码 　　　　 异常层次结构　　异常层次结构应该从一些十分健壮而又通用的异常入手 如 ApplicationException 如果您将顶级异常搞得太具体 那么其结果是您今后将不得不重新构造层次结构 以适应某些较通用的情况 　　　　因此 让我们假定您的应用程序要求 NoSuchBookException InsufficientFundsException 和 SystemUnavailableException 您不必创建这三个异常 让它们继承 ApplicationException 然后只需提供极少几个必须的构造器来创建格式化的消息 清单 是此类异常层次结构的示例 　　　　清单 异常层次结构 package ibm library;　　import ibm ApplicationException;　　public class NoSuchBookException extends ApplicationException {　　public NoSuchBookException(String bookName String libraryName) {　　super( The book + bookName + was not found in the +　　libraryName + library );　　}　　}　　　　当需要编写大量专用异常时 异常层次结构极大地简化了工作 对于一个异常 为每个异常类添加一个或两个构造器 所花费时间很少不超过几分钟 您还经常需要给这些更具体的异常（这些异常也是主应用程序异常的子类）提供子类 以提供更具体的异常 例如 您可能需要 InvalidTitleException 和 BackorderedException 来继承 NoSuchBookException 　　　　企业应用程序在构建时通常都不会注意异常处理 尽管依靠低级异常（如 RemoteException 和 NamingException）很容易（有时也很诱人） 但如果一开始就建立一个可靠的 深思熟虑的异常模型 则您将在应用程序上少花很多精力 创建一个嵌套的 层次结构化的异常框架将改进代码的可读性及其可用性 lishixinzhi/Article/program/Java/Javascript/201311/25400