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

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

　　异常抛出策略

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

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

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

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

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

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

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