J2EE系统异常的处理准则

核心提示： 1）、DAO的接口不被异常所污染，假设你抛出了SQLException，J2EE系统异常的处理准则(2)，以后要是换了Spring DAO模板，那DAO接口就不再抛出了SQLException，然后在控制层（Action）中，调用了好多Service去完成一个业务，这样，你的接口抛出异常就是对接

1）、DAO的接口不被异常所污染，假设你抛出了SQLException，以后要是换了Spring DAO模板，那DAO接口就不再抛出了SQLException，这样，你的接口抛出异常就是对接口的污染。

2）、DAO异常向外传播给更高层处理，以便异常的错误原因不丢失，便于排查错误或进行捕获处理。

这里还有一个设计上常常令人困扰的问题：很多人会问，那定义一个什么样的异常抛出呢，或者是直接抛出一个throw RuntimeException(e)? 对于这个问题，需要分场合，如果系统小，你可以直接抛出一个throw RuntimeException(e)，但对于一个庞大的多模块系统来说，不要抛这种原生的非检查异常，而要抛出自定义的非检查异常，这样不但利于排错，而且有利于系统异常的处理，通常针对每一个模块，粗粒度的定义一个运行时DAO异常。比如：throw new ModelXxxDAORuntimeException(".....",e)，对于msg信息，你可写也可不写，根据需要灵活抛出。

这里常见一个很愚昧的处理方式，为每个DAO定义一个异常，呵呵，这样累不累啊，有多大意义，在Service层中调用时候，如果要捕获，还要捕获出一堆异常。这样致命的问题是代码混乱，维护困难，阅读也困难，DAO的异常应该是粗粒度的。

二、业务层异常处理

习惯上把业务层称之为Service层或者服务层，Service层的代表的是业务逻辑，不要迷信分太多太多层有多大好处，除非需要，否则别盲目划分不必要的层，层越多，效率越差，根据需要够用就行了。

Service接口中的每个方法代表一个特定的业务，而这个业务一定是一个完整的业务，通常会看到一些傻X的做法，数据库事务配置在 Service层，而Service的实现就是DAO的直接调用，然后在控制层（Action）中，调用了好多Service去完成一个业务，你气得已经无语了，低头找砖头去！！！