首先应该明白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信息，可写也可不写，根据需要灵活抛出。
二、业务层异常处理
习惯上把业务层称之为Service层或者服务层，Service层的代表的是业务逻辑，不要迷信分太多太多层有多大好处，除非需要，否则别盲目划分不必要的层，层越多，效率越差，根据需要够用就行了。
一般来说一个小模块对应一个Service，当然也许有两个或多个，针对这个模块的Service定义一个非检查异常，以应付那些不可避免的异常检查，这个自定义异常可以简单的命名为XxxServiceRuntimeException，将捕获到的异常顺势转译为非检查异常后抛出。
但是还有一种情况，由于一些特殊的限制，如果某个异常一旦发生，必须做什么什么处理，而这种处理时硬性要求，或者调用某个Service方法，必须检查处理什么异常，也可以抛出非检查的自定义异常，往往出现这种情况的是政治原因。不推崇这种做法，但也不排斥。
总之，对于接口，尽可能不去用异常污染它。
三、控制层异常
控制层说的简单些就是常见的Action层，主要是控制页面请求的处理。控制层通常都依赖于Service层，现在比较流行的框架对控制层做得都相当的到位，比如Struts、SpringMVC等等，他们的控制层框架会捕获业务层的所有异常，并在控制层中声明可能抛出Exception，因此控制层一般不处理什么异常。
如果是控制层中因为调用了一些非检查异常的方法，比如IO操作等，可以简单处理下异常，保证流的安全，这才是目的。
四、显示层异常处理
对于页面异常，处理的方式多种多样，一是不处理异常，一旦异常了，页面就报错。二是定义出错页面，根据异常的类型以及所在的模块，导航到出错页面。
一般来说，出错页面是更友好的做法。
另外还有特殊的处理方式，展示页面的模板可以捕获异常，并根据情况将异常信息铺到相应的位置，这样就更友好了，不过复杂度较高。
怎么处理，就看需要了。
五、总结
1）、对于异常处理，应该从设计、需要、维护等多个角度综合考虑，有一个通用准则：千万别捕获了 异常什么事情都不干，这样一旦出现异常了，你没法依据异常信息来排错。
2）、对于J2EE多层架构系统来说，尽可能避免（因抛出异常带来的）接口污染。
--转自
该贴由koei123转至本版2015-7-26 22:55:01
当前位置：
论坛首页 »
自由讨论区 »
Android, Python及开发编程讨论区
»
发起投票
技术讨论
加好友
发消息
2015-6-16 17:56:10 |
赞(
操作
