一个用于J2EE应用程序的异常处理框架 - 编程入门网

一个用于J2EE应用程序的异常处理框架

在大多数Java项目中，大部分代码都是样板代码。异常处理就属于此类代码。即使业务逻辑只有3到4行代码，用于异常处理的代码也要占10到20行。本文将讨论如何让异常处理保持简单和直观，使开发人员可以专心于开发业务逻辑，而不是把时间浪费在编写异常处理的样板代码上。本文还将说明用于在J2EE环境中创建和处理异常的基础知识和指导原则，并提出了一些可以使用异常解决的业务问题。本文将使用Struts框架作为表示实现，但该方法适用于任何表示实现。

使用checked和unchecked异常的场景

您是否曾经想过，为什么要在编写好的代码块周围放置一个try-catch块，即便明知道无法对这些异常进行什么处理，而只满足于把它们放在catch块中？您可能想知道，为什么不能把这项工作放在一个集中的地方完成？在大多数情况下，这个地方对于J2EE应用程序来说就是一个前端控制器。换句话说，开发人员不会因为它们而受到干扰，因为根本不必很多地过问它们。但是，如果一个方法名称包含一个throws子句，会出现什么情况呢？开发人员或者必须捕捉这些异常，或者把它们放在自己的方法的throws子句中。这就是痛苦的根源！幸运的是，Java API有一类叫做unchecked exception的异常，它们不必捕捉。但是，仍然存在一个问题：根据什么来决定哪些是checked异常，哪些是unchecked异常？下面给出一些指导原则：

终端用户无法采取有效操作的异常应该作为unchecked异常。例如，致命的和不可恢复的异常就应该是unchecked。把XMLParseException（在解析XML文件时抛出）作为checked异常没有任何意义，因为惟一能够采取的措施就是基于异常跟踪来解决根本问题。通过扩展java.lang.RuntimeException，可以创建自定义的unchecked异常。

在应用程序中，与用户操作相关的异常应该是checked异常。checked异常要求客户端来捕捉它们。您可能会问，为什么不把所有异常都当作是unchecked。这样做的问题在于，其中一些异常无法在正确的位置被捕捉到。这会带来更大的问题，因为错误只有在运行时才能被识别。checked异常的例子有业务确认异常、安全性异常等等。

异常抛出策略

只捕捉基本应用程序异常（假定为BaseAppException）并在throws子句中声明

在大多数J2EE应用程序中，关于针对某个异常应该在哪一界面上显示哪条错误消息的决策只能在表示层中做出。这会带来另一个问题：为什么我们不能把这种决策放在一个公共的地方呢？在J2EE应用程序中，前端控制器就是一个进行常见处理的集中位置。

此外，必须有一种用于传播异常的通用机制。异常也需要以一种普适的方式得到处理。为此，我们始终需要在控制器端捕捉基本应用程序异常BaseAppException。这意味着我们需要把BaseAppException异常（只有这个异常）放入可以抛出checked异常的每个方法的throws子句中。这里的概念是使用多态来隐藏异常的实际实现。我们在控制器中捕捉BaseAppException，但是所抛出的特定异常实例可能是几个派生异常类中的任意一个。借助于这种方法，可以获得许多异常处理方面的灵活性：

不需要在throws子句中放入大量的checked异常。throws子句中只需要有一个异常。

不需要再对应用程序异常使用混乱的catch块。如果需要处理它们，一个catch块（用于BaseAppException）就足够了。

开发人员不需要亲自进行异常处理（日志记录以及获取错误代码）。这种抽象是由ExceptionHandler完成的，稍后本文会就此点进行讨论。

即使稍后把更多异常引入到方法实现中，方法名称也不会改变，因此也不需要修改客户端代码，否则就会引起连锁反应。然而，抛出的异常需要在方法的Javadoc中指定，以便让客户端可以看到方法约束。

下面给出抛出c

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!