工業級應用中關于異常封裝的一些感悟

        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