wm2395的空间

我们一直在努力....

EJB工程异常处理

标签: EJB 异常 处理

对于处理异常需要有一定的策略,要知道分那几种异常,并且要在那一层进行捕获。下面简单介绍一下异常的分类和

异常处理基础知识,解决系统错误的第一步是建立一个与生产系统具有相同构造的测试系统,然后跟踪导致抛出异常的所有代码,以及代码中的所有不同分支。在分布式应用程序中,很可能是调试器不工作了,所以,您可能将用 System.out.println() 方法跟踪异常。 System.out.println 尽管很方便,但开销巨大。在磁盘 I/O 期间, System.out.println I/O 处理进行同步,这极大降低了吞吐量。在缺省情况下,堆栈跟踪被记录到控制台。但是,在生产系统中,浏览控制台以查看异常跟踪是行不通的。这里的解决方案显然是使用一个日志实用程序。采用恰当的编码约定,日志实用程序将负责精确地记录下任何类型的消息,不论是系统错误还是一些警告。日志组件的建立将稍后介绍。

EJB层:执行系统级任务,如使用JNDI或数据库。尽管这些任务最终将被给合并到业务逻辑中,但是最好用像RemoteException之类的系统级异常来表示

                                      他们。

Web层:web层处理业务级异常,因为web层通常由执行业务任务的最终用户

                         驱动的

A. 系统级别的异常,在通常情况下是由JVM作为RuntimeExcetion的子类抛出。例如, NullPointerException ArrayOutOfBoundsException 将因代码中的错误而被抛出。另一种类型的系统异常在系统碰到配置不当的资源(例如,拼写错误的 JNDI 查找(JNDI lookup))时发生。在这种情况下,系统就将抛出一个受查异常。捕获这些受查系统异常并将它们作为非受查异常(unchecked exception)抛出颇有意义。最重要的规则是,如果您对某个异常无能为力,那么它就是一个系统异常并且应当作为非受查异常抛出。

B. 应用程序的异常:应用程序异常是一种定制异常,是由应用程序或第三方库抛出。这些本质上是受查异常,它们预示了业务逻辑中的某个条件尚未满足。在这样的情况下,EJB 方法的调用者可以得体地处理这种局面并采用另一条备用途径。

C. JVM异常:这种类型的异常由 JVM 抛出。 OutOfMemoryError 就是 JVM 异常的一个常见示例。对 JVM 异常您无能为力。它们表明一种致命的情况。唯一得体的退出办法是停止应用程序服务器(可能要增加硬件资源),然后重新启动系统。

 

嵌套的异常,在设计可靠的异常处理时,要考虑的第一件事情就是对低级的或系统级异常进行抽象化。这些核心Java异常通常会报告网络流量中的错误,JNDIRMI问题,或者是应用程序中的其它技术问题。RemoteExceptionEJBExceptionNamingExecption是企业java编程中低级异常的常见例子。如果是应用程序中的代码要访问这些异常中的信息,所以在这种情况下不能轻易抛弃这些异常。所以设计一个异常类,让它包含这些低级的异常。这个类的定义可以参考http://www.ibm.com/developerworks/cn/java/j-ejb01283/index.html中的定义。

 

 


    分享: 收藏到CSDN 收藏到javaeye 收藏到博客园 收藏&分享
  • 浏览 (254)
  • 评论 (0)
  • 发表于 2009-04-09 18:18
  • EJB系列
    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论


发表评论

最近访客
关注此文的人们还关注