工业级应用中关于异常封装的一些感悟

        java的异常体系想必大家都熟记于心的,那么在日常的编码过程中,大家又是如何实施的呢?针对checked和unchecked exception大家的理解又有多少呢?

        几乎所有的书本上都给出了一个conclusion,如果日常事务能从异常中恢复,那么建议用checked exception,如果不能recover from,那么就是unchecked的了.

        大家想过没有,这里的恢复指的是什么?真的不能恢复吗?堆栈,thread又是如何表现的呢?

        this exception that bug,静观皆自得.好了,开场白过后,这里,主要总结一下自己对java exception的理解,也欢迎大家留言,发表自己的心得~

(1)  一种简单的checked,unchecked exception的理解是,将checked exception作为业务异常去使用(关注它,则处理它,不关注,re-throw),可以使用errorcode之类的进行wrap,不要迷恋recover from,自己去实地感知一下,就全了然了;

(2) checked exception有额外的编码开销,君不见一会throws one exception from method ,一会又throw new xxxexception from exception spot,同时过多的re-throw exception造成了堆栈异常庞杂(字节码层面的表现尤为让人惊讶，建议大家翻看asm源码),尤其在异常抛出方面不讲究的话,很有可能造成信息混乱,建议大家研究一下throwable的printstacktrace方法实现;

(3)  关于异常translate,我这里简单总结了一下,编码过程中一般会遇到两类,一类是 checked exception translate unchecked exception(实例代码如下),一类是error translate unchecked exception,使用template模式建立通用异常处理程式,简化异常处理,如有可能，可以使用aop拦截集成点异常,让自己永远处于问题追踪的主动方(关于这一点，可以参考我的一篇博客中的exceptionaspect部分，地址:http://blog.csdn.net/fengjia10/article/details/7341180).但需要注意的是，spring的aop永远只会帮你拦截runtimeexception~

(4) 建立分级的异常监控,预警机制.(使用脚本语言,诸如perl,python等主动,被动兼施)；

(5) 有技巧的"吞掉"异常.不按套路出牌的人，永远让人难以防备，关于这一点，可以研习一下jetty的continuation异步模型；

(6)  尝试使用scala（或者java7+的多重捕获）,与java不同，scala里全然是unchecked exception。另外通过模式匹配，异常处理逻辑，代码可读性也更好.如：

补充篇：

        最近设计openapi的时候，由于要和前端进行交互，后端用的webx3框架，部分

异常采用了其pipeline处理，部分采用了编码映射处理。具体讲，就是错误码与状态码进行编排，前端按需所示（框架层面搂住5xx，4xx状态码，应用层面对其它码进行个性化展示。当然也可以采用位运算取而代之码编排）。示例代码如下：

然后在全局拦截点进行处理，实例代码如下：

前端返回rpc结果为:

剩下的就一目了然了吧～

下面给出一些比较有启发意义的异常处理文献:

3. http://code.google.com/p/guava-libraries/wiki/throwablesexplained