J2EE定制一个用来处理错误的异常处理框架

1、为 J2EE 定制一个用来处理错误的异常 处理框架 来源 :为 J2EE 定制一个用来处理错误的异常处理框架回顾一下你上一个 J2EE 工程, 是否遇到过类似错误没有记入日志或者被多 次记录的情况 ? 是否只是因为在某处代码吃 掉了异常导致你花费无数次时间来 跟踪一个 bug? 是否你的用户直接看到了堆栈的跟踪信息 ? 如果这样的话, 你可能 需要一种通用的异常管理的策略和一些补充的 代码。这篇文章为你提供了在 J2EE 项目中通过使用错误处理框架使用一些策略的基础。Java中关于异常处理的争论可以被认为是一种信仰上的争执 :一方面,强 制异常 (checked exceptions的支持者认

2、为调用者应该处理他们调用代码出现 的异常 ; 另一方面,非强制 (unchecked exceptions异常的追随者认为强制异常 混乱了代码,而且通常客户端不能立即处理,那为什么还要检查他呢。作为初级工程师,我们首先信奉的是强制异常,但几年后,在使用 N 久的 try/catch/finally后,我们开始转向非强制异常了。因为我们开始相信一些处 理错误状况的基本规则 :如果需要处理异常,那么就处理如果处理不了,就抛出如果抛不了,就用非强制的基类异常包装后再抛出但这些异常被抛到最顶层时会怎么样呢 ? 对这种情况,我们有一个底线确保 错误信息被记录并且用户得到正确的提示。本文提供了另外一种框架

3、来处理异常,它扩展了“Create anApplication-Wide User Session for J2EE”所提出的企业应用 session 工具。 使用此框架的 J2EE 应用将 :总是向用户提供有意义的错误信息记下未处理的错误环境,并且只记录一次在日志文件中用唯一的请求 ID 号对异常进行编号,以便进行高精度的调试 在各层中设置一个强壮的、可扩展的,而又简单的策略来处理异常为了搭建框架,我们运用了面向状态编程 (AOP, aspect-oriented programming 、设计模式和使用 XDoclet 进行代码生成。为什么我们需要通用的错误处理方法在项目的开始,我们会做一

4、些关键性的系统架构决定,如 :系统中的元素如 何交互 ? 会话状态保存在哪儿 ? 哪种通信协议会被使用等等。 但这里并没有包含错 误处理。因而每个开发人员都可以任意决定如何定义、分类、建模和处理错误。 作为一个开发人员,你可以想象在这种方式下的结果 :1. 臃肿的日志 :每个 try/catch都包含 log 语句, 这导致被污染的代码生成 臃肿和多余的日志入口。2. 多余的实现 :同一类型的错误有不同的表示,这导致处理的复杂化。3. 破碎的封装 :来自其他组件的异常被定义为方法标识的一部分, 这导致接 口和实现的分离被打破了。4. 不明确的异常定义 :方法签名通常采用抛出 java.lang

5、.Exception , 这导 致客户端不能明确得到方法错误的语义。通常没有定义异常处理策略的借口是 :java已经提供了异常处理。这是事 实, java 也提供一贯的定义、通信、传播及响应异常的工具。但开发人员需要 决定如何在实际的项目中使用这些服务。几个方面是必须要考虑的,如 :1. 检查或不检查异常 :是否应该检查或不检查新异常类 ?2. 异常的使用者 :究竟是谁需要知道什么时候会发生未处理的异常及由谁 来负责记录及通知操作人员 ?3. 基础的异常层次 :异常需要包含什么信息及异常层次需要反映什么语义 ?4. 传递 ; 是否未处理的异常会被定义或传递给别的异常类, 及他们如何在分 布式环境中传递 ?5. 解释 :未处理的异常如何被解释为可阅读的,甚至支持多语言的信息 ? 在框架中封装规则,要快 !我们给出的通用异常处理策略是基于如下的因素 :使用非强制的异常 :使用强制异常, 调用者要被迫处理他们几乎不能处理的 错误。 非强制的异常则给调用者一个选择。 在使用第三方类库时, 你不能控制 异 常是强制或非强制的。 这种情况下, 你需要用非强制异常来包含强