在实际的j2ee项目中,系统内部难免会出现一些异常,如果把异常放任不管直接打印到浏览器可能会让用户感觉莫名其妙,也有可能让某些用户找到破解系统的方法。 出来工作一年时间了,我也大概对异常处理有了一些了解,在这呢小弟简单介绍下个人对异常处理的见解,抛砖引玉,希望各位大神提出宝贵的意见和建议。
就拿spring+struts2+hibernate项目说明:通常一个页面请求到后台以后,首先是到action(也就是所谓mvc的controller),在action层会调用业务逻辑service,servce层会调用持久层dao获取数据。最后执行结果会汇总到action,然后通过action控制转发到指定页面,执行流程如下图所示:
而这三层其实都有可能发生异常,比如dao层可能会有SQLException,service可能会有NullPointException,action可能会有IOException,一但发生异常并且程序员未做处理,那么该层不会再往下执行,而是向调用自己的方法抛出异常,如果dao、service、action层都未处理异常的话,异常信息会抛到服务器,然后服务器会把异常直接打印到页面,结果就会如下图所示:
其实这种错误对于客户来说毫无意义,因为他们通常是看不懂这是什么意思的。 刚学java的时候,我们处理异常通常两种方法:①直接throws,放任不管;②写try...catch,在catch块中不作任何操作,或者仅仅printStackTrace()把异常打印到控制台。第一种方法最后就造就了上图的结果;而第二种方法更杯具:页面不报错,但是也不执行用户的请求,简单的说,其实这就是bug(委婉点:通常是这样)!
那么发生异常到底应该怎么办呢?我想在大家对java异常有一定了解以后,会知道:异常应该在action控制转发之前尽量处理,同时记录log日志,然后在页面以友好的错误提示告诉用户出错了。大家看下面的代码:
如果按照上面的方式处理异常以后,我们用户最后看到的页面可能就会是下面这种形式(我想这种错误提示应该稍微友好点了吧):
然后我们回到刚才处理异常的地方,如果大家积累了一些项目经验以后会发现使用上面那种处理异常的方式可能还不够灵活: ①因为spring把大多数非运行时异常都转换成运行时异常(RuntimeException)最后导致程序员根本不知道什么地方应该进行try...catch操作 ②每个方法都重复写try...catch,而且catch块内的代码都很相似,这明显做了很多重复工作而且还很容易出错,同时也加大了单元测试的用例数(项目经理通常喜欢根据代码行来估算UT case) ③发生异常有很多种情况:可能有数据库增删改查错误,可能是文件读写错误,等等。用户觉得每次发生异常都是“访问过程中产生错误,请重试”的提示完全不能说明错误情况,他们希望让异常信息更详尽些,比如:在执行数据删除时发生错误,这样他们可以更准确地给维护人员提供bug信息。
如何解决上面的问题呢?我是这样做的:JDK异常或自定义异常+异常拦截器 struts2拦截器的作用在网上有很多资料,在此不再赘述,我的异常拦截器原理如下图所示:
然后在异常拦截器对异常进行处理,看下面的代码:
需要注意的是:在使用instanceof判断异常类型的时候一定要从子到父依次找,比如BaseException继承与RuntimeException,则必须首先判断是否是BaseException再判断是否是RuntimeException。
最后在error JSP页面显示具体的错误消息即可:
以上方式可以拦截后台代码所有的异常,但如果出现数据库连接异常时不能被捕获的,大家可以使用struts2的全局异常处理机制来处理:
上面这是一个很简单的异常拦截器,大家可以使用自定义异常,那样会更灵活一些。
以上异常拦截器可以使用其它很多技术替换:比如spring aop,servlet filter等,根据项目实际情况处理。
【补充】ajax也可以进行拦截,但是因为ajax属于异步操作,action通过response形式直接把数据返回给ajax回调函数,如果发生异常,ajax是不会执行页面跳转的,所以必须把错误信息返回给回调函数,我针对json数据的ajax是这样做的:
以上是个人拙见,勿拍砖,谢谢。
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
| |
返回顶楼 | |
发表时间:2011-06-09
不错,我之前基于struts1也是类似这样的处理思路;
这样在业务和数据层到异常可以只捕获再抛出新的定义异常;剩下交拦截器处理。 记录log的工作还是没从业务和数据层剥离出来,传统的log记录是在数据层-业务层-控制层分别记录来跟踪出现bug的程序流程;如果在拦截器那里记录日志,又担心没法记录详细的bug出现流程信息;是否根据捕获的exception实例中可以获取到?如果可以,那如果存在业务层和数据层都有spring代理管理的话,又该如何? | |
返回顶楼 | |
发表时间:2011-06-09
houfeng0923 写道
不错,我之前基于struts1也是类似这样的处理思路;
这样在业务和数据层到异常可以只捕获再抛出新的定义异常;剩下交拦截器处理。 记录log的工作还是没从业务和数据层剥离出来,传统的log记录是在数据层-业务层-控制层分别记录来跟踪出现bug的程序流程;如果在拦截器那里记录日志,又担心没法记录详细的bug出现流程信息;是否根据捕获的exception实例中可以获取到?如果可以,那如果存在业务层和数据层都有spring代理管理的话,又该如何? 异常的重要信息是放在Throwable中的,只要Throwable不要丢失,就不会有问题 try{ .... }catch(IOException e){ throw new RuntimeException(e); } 业务层和数据层由spring代理也不会有问题,只要spring未对异常进行处理消化,最终异常始终会到action层被拦截器捕获。 | |
返回顶楼 | |
发表时间:2011-06-09
不错,思路清晰,格式良好
如果要针对不同的异常类型做出不同的响应又该如何呢? | |
返回顶楼 | |
发表时间:2011-06-09
damoqiongqiu 写道
不错,思路清晰,格式良好
如果要针对不同的异常类型做出不同的响应又该如何呢? 这位朋友过奖了。 不同异常类型依然通过instanceof来判断,判断后就可以做不同操作 if (e instanceof Exception1) { Exception1 e1 = (Exception1) e; //做其它不不同响应 } else if(e instanceof Exception2){ Exception2re = (Exception2)e; //做其它不不同响应 } | |
返回顶楼 | |
发表时间:2011-06-09
怎么还用DAO呢,现在多数都不要这个层了!
| |
返回顶楼 | |
发表时间:2011-06-10
yangdefeng95802 写道
怎么还用DAO呢,现在多数都不要这个层了!
这个说法求解 | |
返回顶楼 | |
发表时间:2011-06-10
yangdefeng95802 写道
怎么还用DAO呢,现在多数都不要这个层了!
同样求解 | |
返回顶楼 | |
发表时间:2011-06-10
白糖_ 写道
damoqiongqiu 写道
不错,思路清晰,格式良好
如果要针对不同的异常类型做出不同的响应又该如何呢? 这位朋友过奖了。 不同异常类型依然通过instanceof来判断,判断后就可以做不同操作 if (e instanceof Exception1) { Exception1 e1 = (Exception1) e; //做其它不不同响应 } else if(e instanceof Exception2){ Exception2re = (Exception2)e; //做其它不不同响应 } 个人认为,根据异常类的类型来区分异常是不是有些臃肿并且难以扩展。我比较喜欢的做法是,自己定义一个BaseException,继承自RuntimeException,然后给BaseException里弄一个errorCode,用errorCode来区分异常类型,这样你只需要维护一张errorCode与异常类型的对应表,就不用定义那么多Exception类了,维护方便,扩展也方便。抛异常的时候只需设置errorCode,捕获异常之后根据errorCode去判断异常类型并做相应处理。 | |
返回顶楼 | |
发表时间:2011-06-10 最后修改:2011-06-10
highsense 写道
白糖_ 写道
damoqiongqiu 写道
不错,思路清晰,格式良好
如果要针对不同的异常类型做出不同的响应又该如何呢? 这位朋友过奖了。 不同异常类型依然通过instanceof来判断,判断后就可以做不同操作 if (e instanceof Exception1) { Exception1 e1 = (Exception1) e; //做其它不不同响应 } else if(e instanceof Exception2){ Exception2re = (Exception2)e; //做其它不不同响应 } 个人认为,根据异常类的类型来区分异常是不是有些臃肿并且难以扩展。我比较喜欢的做法是,自己定义一个BaseException,继承自RuntimeException,然后给BaseException里弄一个errorCode,用errorCode来区分异常类型,这样你只需要维护一张errorCode与异常类型的对应表,就不用定义那么多Exception类了,维护方便,扩展也方便。抛异常的时候只需设置errorCode,捕获异常之后根据errorCode去判断异常类型并做相应处理。 这位朋友跟我想法一致,目前我们公司项目做整体架构的时候,我就是这样设计的。我上面的意思是在开发过程中,我们可能需要引用其它的组件,而其它的组件的自定义异常是不依赖于目前项目的异常的,所以需要分开处理。 就行下图这样,我们整个项目的异常父类是DywlException(继承自RuntimeException),另外我们把系统权限OSPMS组件整合进来了,所以还需要对权限的异常进行处理。 |
java web项目整体异常处理机制
最新推荐文章于 2023-05-04 10:19:50 发布