J2EE系统异常的处理准则_Android, Python及开发编程讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Android, Python及开发编程讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 1760 | 回复: 0   主题: J2EE系统异常的处理准则        下一篇 
    本主题由 koei123 于 2015-7-26 22:55:01 移动
gunrose
注册用户
等级:新兵
经验:36
发帖:79
精华:0
注册:2011-7-21
状态:离线
发送短消息息给gunrose 加好友    发送短消息息给gunrose 发消息
发表于: IP:您无权察看 2015-6-16 17:56:10 | [全部帖] [楼主帖] 楼主

首先应该明白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



赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论