J2EE系统异常的处理准则

核心提示： 搞明白以上两个问题后再回过头看异常怎么处理，Service层通常依赖DAO，J2EE系统异常的处理准则(3)，而Service层的通常也会因为调用别的非检查异常方法而必须面对异常处理的问题，这里和DAO层又有所不同，尽可能避免（因抛出异常带来的）接口污染，以上论述仅代表个人观点，彼一时，此一时嘛

搞明白以上两个问题后再回过头看异常怎么处理，Service层通常依赖DAO，而Service层的通常也会因为调用别的非检查异常方法而必须面对异常处理的问题，这里和DAO层又有所不同，彼一时，此一时嘛！

一般来说一个小模块对应一个Service，当然也许有两个或多个，针对这个模块的Service定义一个非检查异常，以应付那些不可避免的异常检查，这个自定义异常可以简单的命名为XxxServiceRuntimeException，将捕获到的异常顺势转译为非检查异常后抛出。我喜欢这么做，因为前台是J2EE应用，前台是web页面，它们的Struts2等框架会自动捕获所有Service层的异常，并把异常交给开发者去自由处理。

但是还有一种情况，由于一些特殊的限制，如果某个异常一旦发生，必须做什么什么处理，而这种处理时硬性要求，或者调用某个Service方法，必须检查处理什么异常，也可以抛出非检查的自定义异常，往往出现这种情况的是政治原因。不推崇这种做法，但也不排斥。

总之，对于接口，尽可能不去用异常污染她！

三、控制层异常

控制层说的简单些就是常见的Action层，主要是控制页面请求的处理。控制层通常都依赖于Service层，现在比较流行的框架对控制层做得都相当的到位，比如Struts2、SpringMVC等等，他们的控制层框架会捕获业务层的所有异常，并在控制层中声明可能抛出Exception，因此控制层一般不处理什么异常。

如果是控制层中因为调用了一些非检查异常的方法，比如IO操作等，可以简单处理下异常，保证流的安全，这才是目的。

四、显示层异常处理

对于页面异常，处理的方式多种多样，一是不处理异常，一旦异常了，页面就报错。二是定义出错页面，根据异常的类型以及所在的模块，导航到出错页面。

一般来说，出错页面是更友好的做法。

另外还有特殊的处理方式，展示页面的模板可以捕获异常，并根据情况将异常信息铺到相应的位置，这样就更友好了，不过复杂度较高。

怎么处理，就看需要了。

五、总结

1）、对于异常处理，应该从设计、需要、维护等多个角度综合考虑，有一个通用准则：千万别捕获了异常什么事情都不干，这样一旦出现异常了，你没法依据异常信息来排错。

2）、对于J2EE多层架构系统来说，尽可能避免（因抛出异常带来的）接口污染。

以上论述仅代表个人观点，欢迎交流。

出处：http://lavasoft.blog.51cto.com/62575/244138