异常的处理是每个Java程序员时常面对的问题，但是很多人没有原则，遇到异常也不知道如何去处理，于是遇到检查异常就胡乱 try...catch...一把，然后e.printStackTrace()一下了事，这种做法通常除了调试排错有点作用外，没任何价值。对于运行时异常，则干脆置之不理。

　　原因是很多开发者缺乏对异常的认识和分析，首先应该明白Java异常体系结构，一种分层继承的关系，你必须对层次结构熟烂于心：

　　Throwable（必须检查）

　　Error（非必须检查）

　　Exception（必须检查）

　　RuntimeException（非必须检查）

　　一般把Exception异常及其直接子类（除了RuntimeException之外）的异常称之为检查异常。把RuntimeException以及其子类的异常称之为非检查异常，也叫运行时异常。

　　对于Throwable和Error，则用的很少，一般会用在一些基础框架中，这里不做讨论。

　　下面针对J2EE的分层架构：DAO层、业务层、控制层、展示层的异常处理做个分析，并给出一般处理准则。

　　一、DAO层异常处理

　　如果你用了Spring的DAO模板来实现，则DAO层没有检查异常抛出，代码非常的优雅。但是，如果你的DAO采用了原始的JDBC来写，这时候，你不能不对异常做处理了，因为难以避免的SQLException会如影随形的跟着你。对已这种DAO级别的异常，异常了你又能如何呢？与其这样胡乱try...catch...，囫囵吞枣消灭了异常不如让异常以另外一种非检查的方式向外传递。这样做好处有二：

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

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

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

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