展开全部
异常的类别 异常的分类有不同方式。这里，我们将讨论从 EJB 的角度如何对异常进行分类。EJB 规范将异常大致分成三类： JVM 异常：这种类型的异常由 JVM 抛出。OutOfMemoryError 就是 JVM 异常的一个常见示例。对 JVM 异常您无能为力。它们表明一种致命的情况。唯一得体的退出办法是停止应用程序服务器（可能要增加硬件资源），然后重新启动系统。 应用程序异常：应用程序异常是一种定制异常，由应用程序或第三方的库抛出。这些本质上是受查异常（checked exception）；它们预示了业务逻辑中的某个条件尚未满足。在这样的情况下，EJB 方法的调用者可以得体地处理这种局面并采用另一条备用途径。 系统异常：在大多数情况下，系统异常由 JVM 作为 RuntimeException 的子类抛出。例如，NullPointerException 或 ArrayOutOfBoundsException 将因代码中的错误而被抛出。另一种类型的系统异常在系统碰到配置不当的资源（例如，拼写错误的 JNDI 查找（JNDI lookup））时发生。在这种情况下，系统就将抛出一个受查异常。捕获这些受查系统异常并将它们作为非受查异常（unchecked exception）抛出颇有意义。最重要的规则是，如果您对某个异常无能为力，那么它就是一个系统异常并且应当作为非受查异常抛出。 受查异常是一个作为 java.lang.Exception 的子类的 Java 类。通过从 java.lang.Exception 派生子类，就强制您在编译时捕获这个异常。相反地，非受查异常则是一个作为 java.lang.RuntimeException 的子类的 Java 类。从 java.lang.RuntimeException 派生子类确保了编译器不会强制您捕获这个异常。 清单 1. 三种常见的异常处理做法 100 try { 101 OrderHome homeObj = EJBHomeFactory.getInstance().getOrderHome(); 102 Collection orderCollection = homeObj.findByCustomerId(id); 103 iterator orderItter = orderCollection.iterator(); 104 while (orderIter.hasNext()) { 105 Order orderRemote = (OrderRemote) orderIter.getNext(); 106 OrderValue orderVal = orderRemote.getValue(); 107 if (orderVal.getDate() < "mm/dd/yyyy") { 108 OrderItemHome itemHome = EJBHomeFactory.getInstance().getItemHome(); 109 Collection itemCol = itemHome.findByOrderId(orderId) 110 Iterator itemIter = itemCol.iterator(); 111 while (itemIter.hasNext()) { 112 OrderItem item = (OrderItem) itemIter.getNext(); 113 item.remove(); 114 } 115 orderRemote.remove(); 116 } 117 } 118 } catch (NamingException ne) { 119 throw new EJBException("Naming Exception occurred"); 120 } catch (FinderException fe) { 121 fe.printStackTrace(); 122 throw new EJBException("Finder Exception occurred"); 123 } catch (RemoteException re) { 124 re.printStackTrace(); 125 //Some code to log the message 126 throw new EJBException(re); 127 } EJB 异常处理探试法 EJB 组件应抛出哪些异常？您应将它们记录到系统中的什么地方？这两个问题盘根错结、相互联系，应该一起解决。解决办法取决于以下因素： 您的 EJB 系统设计：在良好的 EJB 设计中，客户机绝不调用实体 EJB 组件上的方法。多数实体 EJB 方法调用发生在会话 EJB 组件中。如果您的设计遵循这些准则，则您应该用会话 EJB 组件来记录异常。如果客户机直接调用了实体 EJB 方法，则您还应该把消息记录到实体 EJB 组件中。然而，存在一个难题：相同的实体 EJB 方法可能也会被会话 EJB 组件调用。在这种情形下，如何避免重复记录呢？类似地，当一个会话 EJB 组件调用其它实体 EJB 方法时，您如何避免重复记录呢？很快我们就将探讨一种处理这两种情况的通用解决方案。（请注意，EJB 1.1 并未从体系结构上阻止客户机调用实体 EJB 组件上的方法。在 EJB 2.0 中，您可以通过为实体 EJB 组件定义本地接口规定这种限制。 处理应用程序异常 在这一部分及其后的几个部分中，我们将更仔细地研究用 EJB 异常处理应用程序异常和系统异常，以及 Web 层设计。作为这个讨论的一部分，我们将探讨处理从会话和实体 EJB 组件抛出的异常的不同方式。 实体 EJB 组件中的应用程序异常 清单 2 显示了实体 EJB 的一个 ejbCreate() 方法。这个方法的调用者传入一个 OrderItemValue 并请求创建一个 OrderItem 实体。因为 OrderItemValue 没有名称，所以抛出了 CreateException。 清单 2 显示了 CreateException 的一个很典型的用法。类似地，如果方法的输入参数的值不正确，则查找程序方法将抛出 FinderException。 然而，如果您在使用容器管理的持久性（CMP），则开发者无法控制查找程序方法，从而 FinderException 永远不会被 CMP 实现抛出。尽管如此，在 Home 接口的查找程序方法的 throws 子句中声明 FinderException 还是要更好一些。RemoveException 是另一个应用程序异常，它在实体被删除时被抛出。 从实体 EJB 组件抛出的应用程序异常基本上限定为这三种类型（CreateException、FinderException 和 RemoveException）及它们的子类。多数应用程序异常都来源于会话 EJB 组件，因为那里是作出智能决策的地方。实体 EJB 组件一般是哑类，它们的唯一职责就是创建和取回数据。会话 EJB 组件中的应用程序异常 清单 3 显示了来自会话 EJB 组件的一个方法。这个方法的调用者设法订购 n 件某特定类型的某商品。SessionEJB() 方法计算出仓库中的数量不够，于是抛出 NotEnoughStockException。NotEnoughStockException 适用于特定于业务的场合；当抛出了这个异常时，调用者会得到采用另一个备用途径的建议，让他订购更少数量的商品。 清单 3. 会话 EJB 组件中的样本容器回调方法 public ItemValueObject[] placeOrder(int n, ItemType itemType) throws NotEnoughStockException { //Check Inventory. Collection orders = ItemHome.findByItemType(itemType); if (orders.size() < n) { throw NotEnoughStockException("Insufficient stock for " + itemType); } }
处理系统异常
系统异常处理是比应用程序异常处理更为复杂的论题。由于会话 EJB 组件和实体 EJB 组件处理系统异常的方式相似，所以，对于本部分的所有示例，我们都将着重于实体 EJB 组件，不过请记住，其中的大部分示例也适用于处理会话 EJB 组件。 当引用其它 EJB 远程接口时，实体 EJB 组件会碰到 RemoteException，而查找其它 EJB 组件时，则会碰到 NamingException，如果使用 bean 管理的持久性（BMP），则会碰到 SQLException。与这些类似的受查系统异常应该被捕获并作为 EJBException 或它的一个子类抛出。原始的异常应被包装起来。清单 4 显示了一种处理系统异常的办法，这种办法与处理系统异常的 EJB 容器的行为一致。通过包装原始的异常并在实体 EJB 组件中将它重新抛出，您就确保了能够在想记录它的时候访问该异常。 清单 4. 处理系统异常的一种常见方式 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (NamingException ne) { throw new EJBException(ne); } catch (SQLException se) { throw new EJBException(se); } catch (RemoteException re) { throw new EJBException(re); } 避免重复记录 通常，异常记录发生在会话 EJB 组件中。但如果直接从 EJB 层外部访问实体 EJB 组件，又会怎么样呢？要是这样，您就不得不在实体 EJB 组件中记录异常并抛出它。这里的问题是，调用者没办法知道异常是否已经被记录，因而很可能再次记录它，从而导致重复记录。更重要的是，调用者没办法访问初始记录时所生成的唯一的标识。任何没有交叉引用机制的记录都是毫无用处的。 请考虑这种最糟糕的情形：单机 Java 应用程序访问了实体 EJB 组件中的一个方法 foo()。在一个名为 bar() 的会话 EJB 方法中也访问了同一个方法。一个 Web 层客户机调用会话 EJB 组件的方法 bar() 并也记录了该异常。如果当从 Web 层调用会话 EJB 方法 bar() 时在实体 EJB 方法 foo() 中发生了一个异常，则该异常将被记录到三个地方：先是在实体 EJB 组件，然后是在会话 EJB 组件，最后是在 Web 层。而且，没有一个堆栈跟踪可以被交叉引用！ 幸运的是，解决这些问题用常规办法就可以很容易地做到。您所需要的只是一种机制，使调用者能够： 访问唯一的标识 查明异常是否已经被记录了 您可以派生 EJBException 的子类来存储这样的信息。清单 5 显示了 LoggableEJBException 子类： 清单 5. LoggableEJBException ? EJBException 的一个子类 public class LoggableEJBException extends EJBException { protected boolean isLogged; protected String uniqueID; public LoggableEJBException(Exception exc) { super(exc); isLogged = false; uniqueID = ExceptionIDGenerator.getExceptionID(); } .. .. } 类 LoggableEJBException 有一个指示符标志（isLogged），用于检查异常是否已经被记录了。每当捕获一个 LoggableEJBException 时，看一下该异常是否已经被记录了（isLogged == false）。如果 isLogged 为 false，则记录该异常并把标志设置为 true。 ExceptionIDGenerator 类用当前时间和机器的主机名为异常生成唯一的标识。如果您喜欢，也可以用有想象力的算法来生成这个唯一的标识。如果您在实体 EJB 组件中记录了异常，则这个异常将不会在别的地方被记录。如果您没有记录就在实体 EJB 组件中抛出了 LoggableEJBException，则这个异常将被记录到会话 EJB 组件中，但不记录到 Web 层中。 清单 6 显示了使用这一技术重写后的清单 4。您还可以继承 LoggableException 以适合于您的需要（通过给异常指定错误代码等）。 清单 6. 使用 LoggableEJBException 的异常处理 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (NamingException ne) { throw new LoggableEJBException(ne); } catch (SQLException se) { throw new LoggableEJBException(se); } catch (RemoteException re) { Throwable t = re.detail; if (t != null && t instanceof Exception) { throw new LoggableEJBException((Exception) re.detail); } else { throw new LoggableEJBException(re); } } 记录 RemoteException 从清单 6 中，您可以看到 naming 和 SQL 异常在被抛出前被包装到了 LoggableEJBException 中。但 RemoteException 是以一种稍有不同 ? 而且要稍微花点气力 ? 的方式处理的。 会话 EJB 组件中的系统异常 如果您决定记录会话 EJB 异常，请使用清单 7 所示的记录代码；否则，请抛出异常，如清单 6 所示。您应该注意到，会话 EJB 组件处理异常可有一种与实体 EJB 组件不同的方式：因为大多数 EJB 系统都只能从 Web 层访问，而且会话 EJB 可以作为 EJB 层的虚包，所以，把会话 EJB 异常的记录推迟到 Web 层实际上是有可能做到的。 它之所以不同，是因为在 RemoteException 中，实际的异常将被存储到一个称为 detail（它是 Throwable 类型的）的公共属性中。在大多数情况下，这个公共属性保存有一个异常。如果您调用 RemoteException 的 printStackTrace，则除打印 detail 的堆栈跟踪之外，它还会打印异常本身的堆栈跟踪。您不需要像这样的 RemoteException 的堆栈跟踪。 为了把您的应用程序代码从错综复杂的代码（例如 RemoteException 的代码）中分离出来，这些行被重新构造成一个称为 ExceptionLogUtil 的类。有了这个类，您所要做的只是每当需要创建 LoggableEJBException 时调用 ExceptionLogUtil.createLoggableEJBException(e)。请注意，在清单 6 中，实体 EJB 组件并没有记录异常；不过，即便您决定在实体 EJB 组件中记录异常，这个解决方案仍然行得通。清单 7 显示了实体 EJB 组件中的异常记录： 清单 7. 实体 EJB 组件中的异常记录 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (RemoteException re) { LoggableEJBException le = ExceptionLogUtil.createLoggableEJBException(re); String traceStr = StackTraceUtil.getStackTrace(le); Category.getInstance(getClass().getName()).error(le.getUniqueID() + ":" + traceStr); le.setLogged(true); throw le; } 您在清单 7 中看到的是一个非常简单明了的异常记录机制。一旦捕获受查系统异常就创建一个新的 LoggableEJBException。接着，使用类 StackTraceUtil 获取 LoggableEJBException 的堆栈跟踪，把它作为一个字符串。然后，使用 Log4J category 把该字符串作为一个错误加以记录。
StackTraceUtil 类的工作原理
在清单 7 中，您看到了一个新的称为 StackTraceUtil 的类。因为 Log4J 只能记录 String 消息，所以这个类负责解决把堆栈跟踪转换成 String 的问题。清单 8 说明了 StackTraceUtil 类的工作原理： 清单 8. StackTraceUtil 类 public class StackTraceUtil { public static String getStackTrace(Exception e) { StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); return sw.toString(); } .. .. } java.lang.Throwable 中缺省的 printStackTrace() 方法把出错消息记录到 System.err。Throwable 还有一个重载的 printStackTrace() 方法，它把出错消息记录到 PrintWriter 或 PrintStream。上面的 StackTraceUtil 中的方法把 StringWriter 包装到 PrintWriter 中。当 PrintWriter 包含有堆栈跟踪时，它只是调用 StringWriter 的 toString()，以获取该堆栈跟踪的 String 表示。 Web 层的 EJB 异常处理 在 Web 层设计中，把异常记录机制放到客户机端往往更容易也更高效。要能做到这一点，Web 层就必须是 EJB 层的唯一客户机。此外，Web 层必须建立在以下模式或框架之一的基础上： 模式：业务委派（Business Delegate）、FrontController 或拦截过滤器（Intercepting Filter） 框架：Struts 或任何包含层次结构的类似于 MVC 框架的框架 为什么异常记录应该在客户机端上发生呢？嗯，首先，控制尚未传到应用程序服务器之外。所谓的客户机层在 J2EE 应用程序服务器本身上运行，它由 JSP 页、servlet 或它们的助手类组成。其次，在设计良好的 Web 层中的类有一个层次结构（例如：在业务委派（Business Delegate）类、拦截过滤器（Intercepting Filter）类、http 请求处理程序（http request handler）类和 JSP 基类（JSP base class）中，或者在 Struts Action 类中），或者 FrontController servlet 形式的单点调用。这些层次结构的基类或者 Controller 类中的中央点可能包含有异常记录代码。对于基于会话 EJB 记录的情况，EJB 组件中的每一个方法都必须具有记录代码。随着业务逻辑的增加，会话 EJB 方法的数量也会增加，记录代码的数量也会增加。Web 层系统将需要更少的记录代码。如果您的 Web 层和 EJB 层在同一地方并且不需要支持任何其它类型的客户机，那么您应该考虑这一备用方案。不管怎样，记录机制不会改变；您可以使用与前面的部分所描述的相同技术。 真实世界的复杂性 到现在为止，您已经看到了简单情形的会话和实体 EJB 组件的异常处理技术。然而，应用程序异常的某些组合可能会更令人费解，并且有多种解释。清单 9 显示了一个示例。OrderEJB 的 ejbCreate() 方法试图获取 CustomerEJB 的一个远程引用，这会导致 FinderException。OrderEJB 和 CustomerEJB 都是实体 EJB 组件。您应该如何解释 ejbCreate() 中的这个 FinderException 呢？是把它当作应用程序异常对待呢（因为 EJB 规范把它定义为标准应用程序异常），还是当作系统异常对待？ 清单 9. ejbCreate() 方法中的 FinderException public Object ejbCreate(OrderValue val) throws CreateException { try { if (value.getItemName() == null) { throw new CreateException("Cannot create Order without a name"); } String custId = val.getCustomerId(); Customer cust = customerHome.fingByPrimaryKey(custId); this.customer = cust; } catch (FinderException ne) { //How do you handle this Exception ? } catch (RemoteException re) { //This is clearly a System Exception throw ExceptionLogUtil.createLoggableEJBException(re); } return null; } 文字太多打不下了，具体你在看看类似的教程
处理系统异常
系统异常处理是比应用程序异常处理更为复杂的论题。由于会话 EJB 组件和实体 EJB 组件处理系统异常的方式相似，所以，对于本部分的所有示例，我们都将着重于实体 EJB 组件，不过请记住，其中的大部分示例也适用于处理会话 EJB 组件。 当引用其它 EJB 远程接口时，实体 EJB 组件会碰到 RemoteException，而查找其它 EJB 组件时，则会碰到 NamingException，如果使用 bean 管理的持久性（BMP），则会碰到 SQLException。与这些类似的受查系统异常应该被捕获并作为 EJBException 或它的一个子类抛出。原始的异常应被包装起来。清单 4 显示了一种处理系统异常的办法，这种办法与处理系统异常的 EJB 容器的行为一致。通过包装原始的异常并在实体 EJB 组件中将它重新抛出，您就确保了能够在想记录它的时候访问该异常。 清单 4. 处理系统异常的一种常见方式 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (NamingException ne) { throw new EJBException(ne); } catch (SQLException se) { throw new EJBException(se); } catch (RemoteException re) { throw new EJBException(re); } 避免重复记录 通常，异常记录发生在会话 EJB 组件中。但如果直接从 EJB 层外部访问实体 EJB 组件，又会怎么样呢？要是这样，您就不得不在实体 EJB 组件中记录异常并抛出它。这里的问题是，调用者没办法知道异常是否已经被记录，因而很可能再次记录它，从而导致重复记录。更重要的是，调用者没办法访问初始记录时所生成的唯一的标识。任何没有交叉引用机制的记录都是毫无用处的。 请考虑这种最糟糕的情形：单机 Java 应用程序访问了实体 EJB 组件中的一个方法 foo()。在一个名为 bar() 的会话 EJB 方法中也访问了同一个方法。一个 Web 层客户机调用会话 EJB 组件的方法 bar() 并也记录了该异常。如果当从 Web 层调用会话 EJB 方法 bar() 时在实体 EJB 方法 foo() 中发生了一个异常，则该异常将被记录到三个地方：先是在实体 EJB 组件，然后是在会话 EJB 组件，最后是在 Web 层。而且，没有一个堆栈跟踪可以被交叉引用！ 幸运的是，解决这些问题用常规办法就可以很容易地做到。您所需要的只是一种机制，使调用者能够： 访问唯一的标识 查明异常是否已经被记录了 您可以派生 EJBException 的子类来存储这样的信息。清单 5 显示了 LoggableEJBException 子类： 清单 5. LoggableEJBException ? EJBException 的一个子类 public class LoggableEJBException extends EJBException { protected boolean isLogged; protected String uniqueID; public LoggableEJBException(Exception exc) { super(exc); isLogged = false; uniqueID = ExceptionIDGenerator.getExceptionID(); } .. .. } 类 LoggableEJBException 有一个指示符标志（isLogged），用于检查异常是否已经被记录了。每当捕获一个 LoggableEJBException 时，看一下该异常是否已经被记录了（isLogged == false）。如果 isLogged 为 false，则记录该异常并把标志设置为 true。 ExceptionIDGenerator 类用当前时间和机器的主机名为异常生成唯一的标识。如果您喜欢，也可以用有想象力的算法来生成这个唯一的标识。如果您在实体 EJB 组件中记录了异常，则这个异常将不会在别的地方被记录。如果您没有记录就在实体 EJB 组件中抛出了 LoggableEJBException，则这个异常将被记录到会话 EJB 组件中，但不记录到 Web 层中。 清单 6 显示了使用这一技术重写后的清单 4。您还可以继承 LoggableException 以适合于您的需要（通过给异常指定错误代码等）。 清单 6. 使用 LoggableEJBException 的异常处理 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (NamingException ne) { throw new LoggableEJBException(ne); } catch (SQLException se) { throw new LoggableEJBException(se); } catch (RemoteException re) { Throwable t = re.detail; if (t != null && t instanceof Exception) { throw new LoggableEJBException((Exception) re.detail); } else { throw new LoggableEJBException(re); } } 记录 RemoteException 从清单 6 中，您可以看到 naming 和 SQL 异常在被抛出前被包装到了 LoggableEJBException 中。但 RemoteException 是以一种稍有不同 ? 而且要稍微花点气力 ? 的方式处理的。 会话 EJB 组件中的系统异常 如果您决定记录会话 EJB 异常，请使用清单 7 所示的记录代码；否则，请抛出异常，如清单 6 所示。您应该注意到，会话 EJB 组件处理异常可有一种与实体 EJB 组件不同的方式：因为大多数 EJB 系统都只能从 Web 层访问，而且会话 EJB 可以作为 EJB 层的虚包，所以，把会话 EJB 异常的记录推迟到 Web 层实际上是有可能做到的。 它之所以不同，是因为在 RemoteException 中，实际的异常将被存储到一个称为 detail（它是 Throwable 类型的）的公共属性中。在大多数情况下，这个公共属性保存有一个异常。如果您调用 RemoteException 的 printStackTrace，则除打印 detail 的堆栈跟踪之外，它还会打印异常本身的堆栈跟踪。您不需要像这样的 RemoteException 的堆栈跟踪。 为了把您的应用程序代码从错综复杂的代码（例如 RemoteException 的代码）中分离出来，这些行被重新构造成一个称为 ExceptionLogUtil 的类。有了这个类，您所要做的只是每当需要创建 LoggableEJBException 时调用 ExceptionLogUtil.createLoggableEJBException(e)。请注意，在清单 6 中，实体 EJB 组件并没有记录异常；不过，即便您决定在实体 EJB 组件中记录异常，这个解决方案仍然行得通。清单 7 显示了实体 EJB 组件中的异常记录： 清单 7. 实体 EJB 组件中的异常记录 try { OrderHome orderHome = EJBHomeFactory.getInstance().getOrderHome(); Order order = orderHome.findByPrimaryKey(Integer id); } catch (RemoteException re) { LoggableEJBException le = ExceptionLogUtil.createLoggableEJBException(re); String traceStr = StackTraceUtil.getStackTrace(le); Category.getInstance(getClass().getName()).error(le.getUniqueID() + ":" + traceStr); le.setLogged(true); throw le; } 您在清单 7 中看到的是一个非常简单明了的异常记录机制。一旦捕获受查系统异常就创建一个新的 LoggableEJBException。接着，使用类 StackTraceUtil 获取 LoggableEJBException 的堆栈跟踪，把它作为一个字符串。然后，使用 Log4J category 把该字符串作为一个错误加以记录。
StackTraceUtil 类的工作原理
在清单 7 中，您看到了一个新的称为 StackTraceUtil 的类。因为 Log4J 只能记录 String 消息，所以这个类负责解决把堆栈跟踪转换成 String 的问题。清单 8 说明了 StackTraceUtil 类的工作原理： 清单 8. StackTraceUtil 类 public class StackTraceUtil { public static String getStackTrace(Exception e) { StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); return sw.toString(); } .. .. } java.lang.Throwable 中缺省的 printStackTrace() 方法把出错消息记录到 System.err。Throwable 还有一个重载的 printStackTrace() 方法，它把出错消息记录到 PrintWriter 或 PrintStream。上面的 StackTraceUtil 中的方法把 StringWriter 包装到 PrintWriter 中。当 PrintWriter 包含有堆栈跟踪时，它只是调用 StringWriter 的 toString()，以获取该堆栈跟踪的 String 表示。 Web 层的 EJB 异常处理 在 Web 层设计中，把异常记录机制放到客户机端往往更容易也更高效。要能做到这一点，Web 层就必须是 EJB 层的唯一客户机。此外，Web 层必须建立在以下模式或框架之一的基础上： 模式：业务委派（Business Delegate）、FrontController 或拦截过滤器（Intercepting Filter） 框架：Struts 或任何包含层次结构的类似于 MVC 框架的框架 为什么异常记录应该在客户机端上发生呢？嗯，首先，控制尚未传到应用程序服务器之外。所谓的客户机层在 J2EE 应用程序服务器本身上运行，它由 JSP 页、servlet 或它们的助手类组成。其次，在设计良好的 Web 层中的类有一个层次结构（例如：在业务委派（Business Delegate）类、拦截过滤器（Intercepting Filter）类、http 请求处理程序（http request handler）类和 JSP 基类（JSP base class）中，或者在 Struts Action 类中），或者 FrontController servlet 形式的单点调用。这些层次结构的基类或者 Controller 类中的中央点可能包含有异常记录代码。对于基于会话 EJB 记录的情况，EJB 组件中的每一个方法都必须具有记录代码。随着业务逻辑的增加，会话 EJB 方法的数量也会增加，记录代码的数量也会增加。Web 层系统将需要更少的记录代码。如果您的 Web 层和 EJB 层在同一地方并且不需要支持任何其它类型的客户机，那么您应该考虑这一备用方案。不管怎样，记录机制不会改变；您可以使用与前面的部分所描述的相同技术。 真实世界的复杂性 到现在为止，您已经看到了简单情形的会话和实体 EJB 组件的异常处理技术。然而，应用程序异常的某些组合可能会更令人费解，并且有多种解释。清单 9 显示了一个示例。OrderEJB 的 ejbCreate() 方法试图获取 CustomerEJB 的一个远程引用，这会导致 FinderException。OrderEJB 和 CustomerEJB 都是实体 EJB 组件。您应该如何解释 ejbCreate() 中的这个 FinderException 呢？是把它当作应用程序异常对待呢（因为 EJB 规范把它定义为标准应用程序异常），还是当作系统异常对待？ 清单 9. ejbCreate() 方法中的 FinderException public Object ejbCreate(OrderValue val) throws CreateException { try { if (value.getItemName() == null) { throw new CreateException("Cannot create Order without a name"); } String custId = val.getCustomerId(); Customer cust = customerHome.fingByPrimaryKey(custId); this.customer = cust; } catch (FinderException ne) { //How do you handle this Exception ? } catch (RemoteException re) { //This is clearly a System Exception throw ExceptionLogUtil.createLoggableEJBException(re); } return null; } 文字太多打不下了，具体你在看看类似的教程
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
