Exception异常处理机制讨论

原创
2014/10/13 21:42
阅读数 150

前言:在前篇笔者的博文之中,笔者就预告了即将写本人的第一篇技术博文,与Exception相关的。后来想想,最近也差不多转正了,于是乎,把以下的文章归类于试用期工作总结系列(既然是系列也应该会有后文,后面打算写篇有关OO面向对象设计的,以及关于maven的)。

先说说这段试用期期间,笔者所在的项目组,本人做的工作,都是差不多跟HttpClient这个类库打交道的。因此问题就来了,大家都知道,HttpClient在遇到网络不稳定时是很容易发生异常的。笔者维护的一段最常用的一个类,就最起码有3段是必须和HttpClient打交道的逻辑。在国庆回来后的第一天,同事就跟我说这个项目部署上去的时候出现异常日志了(后来经过同事跟我说,最严重的不是出异常的问题,而是出了异常之后为什么项目就不执行了)。在此之前,笔者也有在日常的测试中遇到这个问题,在经过了初步分析之后,怀疑是在一些代码中因为throwsException (该Excetpion经过包装后就是RuntimeExcetpion了,项目中使用的是Groovy,而调用者并没有捕获异常什么的,所以就杯具了(这也是笔者写这篇文的起因,以前一直觉得如何处理Exception在一些项目中,应该是一个很值得探讨的问题。但因为笔者自身的技术水平有限,因此在这篇文章里,发表的一些看法也只能算是个人一些粗浅的看法,期望各位看到这篇文的看官们,都能给本人提一些如何优雅的处理Exception的看法)。后来这个问题,也初步解决了,解决方案大概是:所有HttpClient抛出的相关异常都统一交给业务逻辑层捕获,在底层的一些HttpClient相关类中,是不处理异常的,而是包装后throws了一个自定义的异常(这种把异常都交给业务逻辑层或者统一一个类来处理也不是太好,像一些底层的HttpClient处理工具类,这些工具类如果把异常都throws出去,那么意味着调用者就都要处理这个异常了)。在国庆前的一段时间,曾经想通过spring aopThrowsAdvice来处理这种全局的Exception(但后来发现这种方案不怎么可行,这种aop的方案的思路是,代码里不显式处理异常,而是交给代理类去处理,这样子就可以省去一些相同的代码)。

转入正题,在这个可以说是bug的问题初步解决之后,我就开始在思考如何正确的处理Exception了(以前其实也有大概考虑过这个问题,下面是我以我少数的经验得出的一些最佳实践,也是在此次的问题中得出来的一点经验。本来想把Effect java中的一些建议搬出来的,但是个人觉得Effect java的中文翻译实在是有点一般)

1:不要轻易忽视异常,在代码中应该避免使用try finnaly这种语句。一些Check exception可以在有需要的时候转换为Runtime,异常处理不应该简单的使用e.printStackTrace()这种语句简单处理,应该相应的记录日志

2:在一些项目中常见的工具类,不应该再throws exception让别人去处理了,这样在调用者代码里会多出一些重复的代码,工具类应该可以自己进行一些异常的处理

3web工程中个人感觉应该避免把业务逻辑层的出现一些异常扩散到action层,action层的异常处理,可以考虑一些框架内置的解决方案(类似Struts2action,一些example程序是直接throws Exception的)

后记:个人水平有限,本来这篇也想着应该有比较多东西可写的,但目前来看也只能先写到这里了,下章节开始要差不多动工那篇OO的文章和maven的文章了。

 


展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部