＋设为首页 ＋添加到收藏夹
srikanth shenoy（srikanth@srikanth.org）
j2ee 顾问 【程序编程相关:Apple II liker progr】 【推荐阅读:在ASP.NET中创建安全的web站点（】2002 年 5 月 【扩展信息:网页中控制是否打印元素的两种方法】 随着 j2ee 成为企业开发平台之选,越来越多基于 j2ee 的应用程序将投入生产.j2ee 平台的重要组件之一是 enterprise javabean（ejb）api.j2ee 与 ejb 技术一起提供了许多优点,但随之而来的还有一些新的挑战.特别是企业系统,其中的任何问题都必须快速得到解决.在本文中,企业 java 编程老手 srikanth shenoy 展现了他在 ejb 异常处理方面的最佳做法,这些做法可以更快解决问题.在 hello-world 情形中,异常处理非常简单.每当碰到某个方法的异常时,就捕获该异常并打印堆栈跟踪或者声明这个方法抛出异常.不幸的是,这种办法不足以处理现实中出现的各种类型的异常.在生产系统中,当有异常抛出时,很可能是最终用户无法处理他或她的请求.当发生这样的异常时,最终用户通常希望能这样:
有一条清楚的消息表明已经发生了一个错误 有一个唯一的错误号,他可以据此访问可方便获得的客户支持系统 问题快速得到解决,并且可以确信他的请求已经得到处理,或者将在设定的时间段内得到处理理想情况下,企业级系统将不仅为客户提供这些基本的服务,还将准备好一些必要的后端机制.举例来说,客户服务小组应该收到即时的错误通知,以便在客户打电话求助之前服务代表就能意识到问题.此外,服务代表应该能够交叉引用用户的唯一错误号与产品日志,从而快速识别问题 — 最好是能把问题定位到确切的行号或确切的方法.为了给最终用户与支持小组提供他们需要的工具与服务,在构建一个系统时,您就必须对系统被部署后可能出问题的所有地方心中有数.
在本文中,我们将谈谈基于 ejb 的系统中的异常处理.我们将从回顾异常处理的基础知识开始,包括日志实用程序的使用,然后,很快就转入对 ejb 技术如何定义与管理不同类型的异常进行更详细的讨论.此后,我们将通过一些代码示例来研究一些常见的异常处理解决方案的优缺点,我还将展示我自己在充分利用 ejb 异常处理方面的最佳做法.
请注意,本文假设您熟悉 j2ee 与 ejb 技术.您应理解实体 bean 与会话 bean 的差异.如果您对 bean 管理的持久性（bean-managed persistence（bmp））与容器管理的持久性（container-managed persistence（cmp））在实体 bean 上下文中是什么意思稍有了解,也是有帮助的.请参阅参考资料部分了解关于 j2ee 与 ejb 技术的更多信息.
异常处理基础知识
解决系统错误的第一步是建立一个与生产系统具有相同构造的测试系统,然后跟踪导致抛出异常的所有代码,以及代码中的所有不同分支.在分布式应用程序中,很可能是调试器不工作了,所以,您可能将用 system.out.println() 方法跟踪异常.system.out.println 尽管很方便,但开销巨大.在磁盘 i/o 期间,system.out.println 对 i/o 处理进行同步,这极大降低了吞吐量.在缺省情况下,堆栈跟踪被记录到控制台.但是,在生产系统中,浏览控制台以查看异常跟踪是行不通的.而且,不能保证堆栈跟踪会显示在生产系统中,因为,在 nt 上,系统管理员可以把 system.out 与 system.err 映射到 ´ ´,在 unix 上,可以映射到 dev/null.此外,如果您把 j2ee 应用程序服务器作为 nt 服务运行,甚至不会有控制台.即使您把控制台日志重定向到一个输出文件,当产品 j2ee 应用程序服务器重新启动时,这个文件很可能也将被重写. 异常处理的原则 以下是一些普遍接受的异常处理原则: 如果无法处理某个异常,那就不要捕获它. 如果捕获了一个异常,请不要胡乱处理它. 尽量在靠近异常被抛出的地方捕获异常. 在捕获异常的地方将它记录到日志中,除非您打算将它重新抛出. 按照您的异常处理必须多精细来构造您的方法. 需要用几种类型的异常就用几种,尤其是对于应用程序异常.第 1 点显然与第 3 点相抵触.实际的解决方案是以下两者的折衷:您在距异常被抛出多近的地方将它捕获;在完全丢失原始异常的意图或内容之前,您可以让异常落在多远的地方.
注:尽管这些原则的应用遍及所有 ejb 异常处理机制,但它们并不是特别针对 ejb 异常处理的.
由于以上这些原因,把代码组装成产品并同时包含 system.out.println 并不是一种选择.在测试期间使用 system.out.println,然后在形成产品之前除去 system.out.println 也不是上策,因为这样做意味着您的产品代码与测试代码运行得不尽相同.您需要的是一种声明控制日志机制,以使您的测试代码与产品代码相同,并且当记录日志以声明方式关闭时,给产品带来的性能开销最小.
这里的解决方案显然是使用一个日志实用程序.采用恰当的编码约定,日志实用程序将负责精确地记录下任何类型的消息,不论是系统错误还是一些警告.所以,我们将在进一步讲述之前谈谈日志实用程序.
日志领域:鸟瞰
每个大型应用程序在开发.测试及产品周期中都使用日志实用程序.在今天的日志领域中,有几个角逐者,其中有两个广为人知.一个是 log4j,它是来自 apache 的 jakarta 的一个开放源代码的项目.另一个是 j2se 1.4 捆绑提供的,它是最近刚加入到这个行列的.... 下一页