Exception异常处理机制讨论

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

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

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

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

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

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

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

 

转载于:https://my.oschina.net/u/1427420/blog/330292