对异常处理的一点思考

最近在网上看了一些文章，关于处理异常的。

1， 对异常处理的三个原则，具体，早抛，晚处理， ( http://today.java.net/pub/a/today/2003/12/04/exceptions.html ）

2， 使用错误代号

( http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html )

3， 使用运行时异常

( http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html )

这三个原则是很有道理的。

1， 在一些书上说，异常要早处理，因为 VM 维护异常栈，要浪费性能。但异常之所以为异常，发生的频率应该不高。早处理的问题是，基本处理不了。因为目前常见的处理异常方式，日志 + 消息，日志可以底层记录，但消息却只能在高层处理。

2， 使用错误代号 , 这一点很有趣，让人联想 MS 的某某错误代号。使用代号，有利于维护一个异常库，国际化也比较方便一点。

3， 使用运行时异常，有利于代码封装，其实比较危险，但我们却可以限制它使用的范围来降低风险。

下面要讨论的处理异常方法就是基于以上三点的。同时我们假设系统是层次分明的，如果系统层次都不分明，讨论异常处理是没有意义的。以下是一个简单的架构分层结构 (Service proxy, BU, Util) ，初始化和请求过程。

 

 

 

1, 首先我们对异常分类。以引发原因异常可以分为内部异常 ( 系统内 ) 和外部异常。内部异常主要是开发过程中不太可能发生的异常和系统维护配置出错导致的异常，比如 ResourceLoader 读取配置文件失败，配置文件的 XML 格式不对， ElementProcessor 解析验证失败。这一类异常通常都是 Fatal 的。 外部异常主要是不恰当的用户调用，网络不可达等。比如用户输入格式不对，数据库服务器无法连接。

2, 根据系统的层次，为每一层新建相应的异常。这里的层次，更有一点功能内聚的模块的意思。不管是业务的还是底层 Util 的，每一层最好只有一个异常类。

4， 穷举系统内的异常。为这些异常在相应模块异常上新建或归入某一个错误代码中。这一步是随着系统开发迭代。 我们以 ResourceLoader 来详细说明一下。

对于 loadPlainResource() 方法来说，内部可能有的异常包括了 FileNotFoundException, IOException, 对于 loadXmlResource() 因为其返回为 Document ，所以还有关于 JAXP 或 JDOM 的异常。

ResourceException	Code	Message
RESOURCE_NOT_FOUND	001	File not found
RESOURCE_READ_FAILED	002	Read file failed
RESOURCE_INVALID_FORMAT	003	XML format not right

随着开发的向前推进，会不断有新的异常加入到这张表。 我们同时还要处理的是高层的异常转译，比如 ResourceException 的 3 个异常类可能只对应 BusinessException 中的一个映射，资源不可达 ESOURCE_UNREACHABLE 。 层次越高，异常越可读。

基于上面的异常类，我们可以定义如下的处理规则。

1， Service 层，抛 BusinessException 。因为只有更上层的才有能力处理异常， 把异常信息返回给客户。

2， BU 层 , 只抛 ( 具体的 )BusinessException 。对于底层的异常，补获，转译 , 抛出。

3， Util 层，统一转译异常。

对 2 的解释，取决于模块间的调用，究竟能不能控制在 Service 层。如果在 BU 层调用其它的 Service 那就只能把抛出的异常放开到 BusinessException 了。

 

写完了,连自己都很乱.

下周SCJP后，再改