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

　　然而，我们要给出一个警告：如果您准备在同一个客户端方法中使用多个接口，而且这些接口都可以抛出RecordNotFoundException异常，那么想要知道是哪个实体引发了这个异常就变得十分困难。如果业务接口是公共的，而且可以被各种外部客户端使用，那么建议只使用特定的异常，而不使用像RecordNotFoundException这样的一般性异常。特定于上下文的异常对于基于数据库的可恢复异常来说非常有用，因为在这种情况下，异常类始终是相同的，不同的只有它们出现的上下文。

　　J2EE应用程序的异常层次结构

　　正如前面讨论的那样，我们需要定义一个异常基类，叫做BaseAppException，它包含了所有应用程序异常的默认行为。我们将把这个基类放到所有可能抛出checked异常的方法的throws子句中。应用程序的所有checked异常都应该是这个基类的子类。有多种定义错误处理抽象的方式。然而，其中的区别更多地是与业务类而不是与技术有关。对错误处理的抽象可分为以下几类。所有这些异常类都是从BaseAppException派生而来。

　　checked异常

　　业务异常：执行业务逻辑时出现的异常。BaseBusinessException是这类异常的基类。

　　数据库异常：与持久化机制进行交互时抛出的异常。BaseDBException是这类异常的基类。

　　安全性异常：执行安全性操作时出现的异常。这类异常的基类是BaseSecurityException。

　　确认异常：在从终端用户处获得确认以执行某个特定任务时使用。这类异常的基类是BaseConfirmationException。

　　unchecked异常

　　系统异常：有时候我们希望使用unchecked异常。例如下面的情况：不想亲自处理来自第三方库API的异常，而是希望把它们包装在unchecked异常中，然后抛出给控制器。有时会出现配置问题，这些问题也不能由客户端进行处理，而应该被当作unchecked异常。所有自定义的unchecked异常都应该扩展自java.lang.RuntimeException类。