EJB 最佳实践

构建更好的异常处理框架

提供更有用的异常而不必牺牲代码的整洁性

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: EJB 最佳实践

敬请期待该系列的后续内容。

此内容是该系列的一部分:EJB 最佳实践

敬请期待该系列的后续内容。

在本系列先前的技巧文章中,异常处理不属于讨论的核心范围之内。但是,您可能会发现一点,那就是我们一直都回避来自 Web 层的低级异常。我们向客户机提供诸如 ApplicationExceptionInvalidDataException 之类的异常,而没有让 Web 层处理象 java.rmi.RemoteExceptionjavax.naming.NamingException 这样的异常。

远程和命名异常是 系统级异常,而应用程序和非法数据异常是 业务级异常,因为它们提交更适用的业务信息。当决定抛出何种类型的异常时,您应该总是首先考虑将要处理所报告异常的层。Web 层通常是由执行业务任务的最终用户驱动的,所以最好用它处理业务级异常。但是,在 EJB 层,您正在执行系统级任务,如使用 JNDI 或数据库。尽管这些任务最终将被合并到业务逻辑中,但是最好用诸如 RemoteException 之类的系统级异常来表示它们。

理论上,您可以让所有 Web 层方法预期处理和响应单个应用程序异常,正如我们在先前的一些示例中所做的一样。但这种方法不适用于长时间运行。让您的委派方法抛出更具体的异常,这是一个好得多的异常处理方案,从根本上讲,这对接收客户机更有用。在这篇技巧文章中,我们将讨论两种技术,它们将有助于您创建信息更丰富、更具体的异常,而不会生成大量不必要的代码。

嵌套的异常

在设计可靠的异常处理方案时,要考虑的第一件事情就是对所谓的 低级系统级异常进行抽象化。这些核心 Java 异常通常会报告网络流量中的错误、JNDI 或 RMI 问题,或者是应用程序中的其它技术问题。 RemoteExceptionEJBExceptionNamingException 是企业 Java 编程中低级异常的常见例子。

这些异常完全没有任何意义,由 Web 层的客户机接收时尤其容易混淆。如果客户机调用 purchase() 并接收到 NamingException ,那么它在解决这个异常时会一筹莫展。同时,应用程序代码可能需要访问这些异常中的信息,因此不能轻易地抛弃或忽略它们。

答案是提供一类更有用的异常,它还包含低级异常。清单 1 演示了一个专为这一点设计的简单 ApplicationException

清单 1. 嵌套的异常
package com.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 1.4 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 msg2 = child.getMessage();
               // If we found a message for the child exception, 
               // we append it.
               if (msg2 != null) {
                   if (msg != null) {
                       msg += ": " + msg2;
                   } else {
                       msg = msg2;
                   }
               }
               // 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 completed 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;
       }
}

清单 1 中的代码很简单;我们已经简单地将多个异常“串”在一起,以创建单个、嵌套的异常。但是,真正的好处在于将这种技术作为出发点,以创建特定于应用程序的异常层次结构。异常层次结构将允许 EJB 客户机既接收特定于业务的异常也接收特定于系统的信息,而不需要编写大量额外代码。

异常层次结构

异常层次结构应该从一些十分健壮而又通用的异常入手,如 ApplicationException 。如果您将顶级异常搞得太具体,那么其结果是您今后将不得不重新构造层次结构,以适应某些较通用的情况。

因此,让我们假定您的应用程序要求 NoSuchBookExceptionInsufficientFundsExceptionSystemUnavailableException 。您不必创建这三个异常,让它们继承 ApplicationException ,然后只需提供极少几个必须的构造器来创建格式化的消息。清单 2 是此类异常层次结构的示例:

清单 2. 异常层次结构
package com.ibm.library;
import com.ibm.ApplicationException;
public class NoSuchBookException extends ApplicationException {
       public NoSuchBookException(String bookName, String libraryName) {
        super("The book '" + bookName + "' was not found in the '" +
            libraryName + "' library.");
    }
}

当需要编写大量专用异常时,异常层次结构极大地简化了工作。对于一个异常,为每个异常类添加一个或两个构造器,所花费时间很少不超过几分钟。您还经常需要给这些更具体的异常(这些异常也是主应用程序异常的子类)提供子类,以提供更具体的异常。例如,您可能需要 InvalidTitleExceptionBackorderedException 来继承 NoSuchBookException

企业应用程序在构建时通常都不会注意异常处理。尽管依靠低级异常(如 RemoteExceptionNamingException )很容易(有时也很诱人),但如果一开始就建立一个可靠的、深思熟虑的异常模型,则您将在应用程序上少花很多精力。创建一个嵌套的、层次结构化的异常框架将改进代码的可读性及其可用性。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  • 查看 Brett McLaughlin 撰写的完整的 EJB 最佳实践系列。
  • Eric Allen 的 诊断 Java 代码专栏是帮助您管理 Java 代码中常见错误的技巧文章“仓库”。
  • Java 架构设计师 Srikanth Shenoy 在其文章“ EJB 异常处理的最佳做法”( developerWorks,2002 年 5 月)中演示了如何在基于 EJB 技术的系统上进行编码以更快地解决问题。
  • Sun Microsystems 的 EJB 技术主页是了解关于 EJB 技术信息的良好起点。
  • 另一个很棒的参考资料是 TheServerSide.com,它提供了关于 J2EE 的文章和信息。
  • developerWorks Java 技术专区可以找到多达数百篇的 Java 技术参考资料。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Java technology
ArticleID=54718
ArticleTitle=EJB 最佳实践: 构建更好的异常处理框架
publish-date=04202003