《JEE中的异常管理及错误跟踪》由会员分享，可在线阅读，更多相关《JEE中的异常管理及错误跟踪（17页珍藏版）》请在金锄头文库上搜索。
1、JEE中的异常管理及错误跟踪 作者： 日期： 注册用户中心 登陆短信帮助 文档wiki专题wiki 开源wiki站内搜索 Matrix首页 Java文栏 业界新闻 资源下载 Java部落格 Java 论坛 网站注册:90970今日注册:85 当前在线:55/413 J2EE中的异常管理及错误跟踪matrix 发表于2005-09-10 作者:Kre Jens ;xMatrix 来自:Javaworld 评价:8/3 评论数:1 点击数:198 收藏 摘要：回忆一下你上一个J2EE工程，是否遇到过类似错误没有记入日志或者被屡次记录的情况？是否只是因为在某处代码吃掉了异常导致你花费无数次时间来跟踪
2、一个bug?是否你的用户直接看到了堆栈的跟踪信息？如果这样的话，你可能需要一种通用的异常管理的策略和一些补充的代码。这篇文章为你提供了在J2EE工程中通过使用错误处理框架使用一些策略的根底本文Matrix永久镜像： 说明：本文可能由Matrix原创，也可能由Matrix的会员整理，或者由Matrix的Crawler在全球知名Java或者其他技术相关站点抓取并永久保存镜像，Matrix会保存所有原来的出处URL，并在显著地方作出说明，如果你觉察出处URL有误，请联系Matrix改正.J2EE中的异常管理及错误跟踪为J2EE定制一个用来处理错误的异常处理框架 Kåre Kjelstr&
3、oslash;m/Jens Schjærff Byager翻译：xMatrix版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明原文地址:中文地址:关键词： J2EE Exception摘要回忆一下你上一个J2EE工程，是否遇到过类似错误没有记入日志或者被屡次记录的情况？是否只是因为在某处代码吃掉了异常导致你花费无数次时间来跟踪一个bug?是否你的用户直接看到了堆栈的跟踪信息？如果这样的话，你可能需要一种通用的异常管理的策略和一些补充的代码。这篇文章为你提供了在J2EE工程中通过使用错误处理框架使用一些策略的根底。(3100个英文单词，2005年7月
4、11日)Java中关于异常处理的争论可以被认为是一种信仰上的争执：一方面，强制异常(checked exceptions)的支持者认为调用者应该处理他们调用代码出现的异常；另一方面，非强制(unchecked exceptions)异常的追随者认为强制异常混乱了代码，而且通常客户端不能立即处理，那为什么还要检查他呢。作为初级工程师，我们首先信奉的是强制异常，但几年后，在使用N久的try/catch/finally后，我们开场转向非强制异常了。因为我们开场相信一些处理错误状况的根本规那么：如果需要处理异常，那么就处理如果处理不了，就抛出如果抛不了，就用非强制的基类异常包装后再抛出但这些异常被抛到
5、最顶层时会怎么样呢？对这种情况，我们有一个底线确保错误信息被记录并且用户得到正确的提示。本文提供了另外一种框架来处理异常，它扩展了“Create an Application-Wide User Session for J2EE(JavaWorld, 2005年3月)所提出的企业应用session工具。使用此框架的J2EE应用将：总是向用户提供有意义的错误信息记下未处理的错误环境，并且只记录一次在日志文件中用唯一的请求ID号对异常进展编号，以便进展高精度的调试在各层中设置一个强壮的、可扩展的，而又简单的策略来处理异常为了搭建框架，我们运用了面向状态编程(AOP，aspect-oriented
6、programming)、设计模式和使用XDoclet进展代码生成。你可以在资源中找到所有代码及一个使用框架的J2EE应用。这些源程序组成了一个名为Rampart的完整框架，当初是为丹麦哥本哈根基于J2EE的电子保健系统应用(EHR, electronic healthcare records)而开发的。为什么我们需要通用的错误处理方法在工程的开场，我们会做一些关键性的系统架构决定，如：系统中的元素如何交互？会话状态保存在哪儿？哪种通信协议会被使用等等。但这里并没有包含错误处理。因而每个开发人员都可以任意决定如何定义、分类、建模和处理错误。作为一个开发人员，你可以想象在这种方式下的结果：1.
7、臃肿的日志：每个try/catch都包含log语句，这导致被污染的代码生成臃肿和多余的日志入口。2. 多余的实现：同一类型的错误有不同的表示，这导致处理的复杂化。3. 破碎的封装：来自其他组件的异常被定义为方法标识的一局部，这导致接口和实现的别离被打破了。4. 不明确的异常定义：方法签名通常采用抛出java.lang.Exception，这导致客户端不能明确得到方法错误的语义。通常没有定义异常处理策略的借口是：java已经提供了异常处理。这是事实，java也提供一贯的定义、通信、传播及响应异常的工具。但开发人员需要决定如何在实际的工程中使用这些效劳。几个方面是必须要考虑的，如：1. 检查或不检
8、查异常：是否应该检查或不检查新异常类？2. 异常的使用者：终究是谁需要知道什么时候会发生未处理的异常及由谁来负责记录及通知操作人员？3. 根底的异常层次：异常需要包含什么信息及异常层次需要反映什么语义？4. 传递；是否未处理的异常会被定义或传递给别的异常类，及他们如何在分布式环境中传递？ 5. 解释：未处理的异常如何被解释为可阅读的，甚至支持多语言的信息？在框架中封装规那么，要快！我们给出的通用异常处理策略是基于如下的因素：使用非强制的异常：使用强制异常，调用者要被迫处理他们几乎不能处理的错误。非强制的异常那么给调用者一个选择。在使用第三方类库时，你不能控制异常是强制或非强制的。这种情况下，你
9、需要用非强制异常来包含强制异常。在使用非强制异常时，最大的让步是你不能再强制调用者来处理异常了。然而作为接口定义的一局部，异常仍是约定的关键局部并且继续成为Javadoc文档的一局部。封装异常处理并在每一层的顶层提供处理器：你可以专注于只处理业务逻辑相关的异常。处理器可以为特定层剩余的异常执行标准操作：记录日志、系统管理提示及转换等等。通过“简单生活方式来建模异常类层次：不要在发现新的错误类型时就创立新的异常类。首先问一下是否可以作为其他类型的变体来对待或者调用者确实需要捕获。记住异常至少在某方面是可以用他的属性来为不同的状况建立变化模型的对象。较少的异常类在开场时是足够的，但也仅在这种情况下
10、可能需要用特定属性来处理。提供有意义的信息给使用者：未处理的异常代表不可预知的事件和问题。告诉用户并且保存细节给技术支持人员。虽然在不同的工程中需求、限制、异常层次及通知机制会有所不同，但许多元素还是一致的。因此为什么不完全地通过框架实现通用的策略呢？依据简单使用原那么的框架是强制使用策略的最好方法。通过jar文件与javadoc之类的可执行工件与开发人员对话比白纸和幻灯片更容易表示架构准那么。然而，你不能要求开发团队直到异常处理策略及附加的框架支持准备完毕后才开场错误处理。错误处理必须在第一个源文件创立时确定。一个好的启动方法是定义根底的异常层次。根底异常层次我们首要的任务是定义一个可以跨工
11、程的通用异常层次。这里的非强制异常基类是UnrecoverableException，由于历史原因，这个名字可能会有些误导。你可以在自己的层次中使用更好的名字当你不想使用强制异常时WrappedException可以提供一种简单通用的传送机制：包裹原来的异常并重新抛出。WrappedException保存原始异常作为内部引用，这使得当类需要原始异常时也可以可以正常工作。当这不重要时，你可以使用SerializableException，他类似于WrappedException，此外还可以在客户端没有对类库作任何假设的情况下使用。虽然我们偏好和推荐非强制异常，但你可以保存强制异常作为可选项。In
12、strumentedException是一个支持强制非强制异常的接口，他遵循一定属性实现模式。他允许异常处理者一致地检查来源页不需要考虑是来自强制或非强制的异常。下面的类图显示了我们根底的异常层次。这时候我们已经拥有了一个策略及相应的一组可以被抛出的异常。现在是时候建立平安网了。防守的底线“创立应用范围的用户会话这篇文章描述了Rampart，一个使用了由企业信息系统层，基于无状态会话bean的业务层及基于网页和标准J2SE客户端的客户层的分层架构。异常可以从任意层次抛出，可以在线处理或者延迟到调用链的最终端。J2SE和J2EE应用效劳器都可以通过捕获未处理的Errors和RuntimeExce
13、ptions来抵御侵入性的行为，通过输出栈信息、记入日志或者执行其他默认的操作。在任何情况下，用户都不应该看到输出信息，通常是没有意义的甚至影响程序稳定性的错误。因此我们必须构建自己的壁垒来提供更好的异常处理机制来维持这一防守的底线看一下列图2:异常可能发生在EJB层的效劳端和网页层，甚至独立的客户端。在第一种情况下，异常停留在同一VM中，也可能被传送到网页层。这儿就是我们要安装的顶层异常处理器的地方。在后一种情况下，异常发生在EJB容器的边缘并且通过RMI连接传递到客户端。必须注意不要传送任何属于效劳端类的异常如来自对象关系映射框架这类的到客户端。而由EJB异常处理器通过使用Serializ
14、ableException作为中介来处理这个问题。在客户端，顶层的Swing异常处理器捕获其他未处理的错误并采取相应措施。异常处理框架在Rampart框架中异常处理器是一个实现了ExceptionHandler接口的类。这个接口仅有一个包含两个参数待处理的Throwable和当前的Thread的方法。方便起见，框架提供了包含根本的实现类ExceptionHandlerBase，他区分Throwable并将其代理给RuntimeException, Error, Throwable和Rampart框架的Unrecoverable的特定的抽象方法来处理。子类提供这些方法的实现并区别处理。下面的类图
15、显示了异常处理器的层次和三个缺省的异常处理器。许多人认为SUN应该在每应用的根底上给J2EE框架内置插入所有容器的钩子。这样就允许自定义错误处理方案、平安及更多可安装的功能，而不需要依赖特定厂商的方案和框架。不幸地是，SUN并没有在EJB标准中提供这样的机制。既然如此，我们只有拿出AOP这个强有力的工具来增加异常处理。我们选择的AspectWerkz框架，可以如下使用方面：public class EJBExceptionHandler implements AroundAdvice private ExceptionHandler handler; public EJBExceptionHandle
