canonical

    在witrix平臺中，異常處理沒有采用java語法支持的checked exception, 也不提倡使用自定義的異常類， 而是定義了少數幾個RuntimeException基類，一般是CommonException(RuntimeException的派生類)。
    在我自己的經驗中，checked exception從未發揮過實質性的作用。checked exception在某種程度上破壞了封裝性原則。我們一般不會在最細的粒度上處理異常，而是在某個統一的模塊節點處進行。如果使用checked exception, 則從最底層的調用到具體異常處理層的整個調用堆棧上的函數都必須明確標記自己不處理該異常，這是完全不必要的負擔。這種細粒度上的負擔往往將程序員引導到 錯誤的方向上去，例如編寫catch塊直接捕獲異常
  try{
     ...
  }catch(MyException e){
     e.printStackTrace();
  }
在witrix平臺中通過包裝類來將checked exception包裝為RuntimeException, 而且除了在最終代碼處理模塊決不屏蔽異常。
 try{
    ...
 }catch(IOException e){
 throw Exceptions.source(e); // 此時會自動trace異常堆棧及異常消息
 }

（后來看到Bruce Eckel的文章Does Java need Checked Exception，發現大家在對待checked exception的態度上倒是心有戚戚焉。）

     一般使用自定義的異常類似乎是要將類名作為錯誤返回碼使用，利用java編譯器可以做所謂的強類型檢查，這實在是一種概念上的浪費。畢竟創建并維護一個 java類還是有一定的代價的，特別是錯誤碼經常變動而且數量不菲。實際上，java類庫的設計中也是盡量重用已有的異常類，例如整個jdbc包只拋出 SQLException異常，xml包只拋出SAXException異常。

     使用異常，常見的方法是拋出一個字符串消息，例如 throw new MyException("the object manager does not contains the object :" + objectName);
這種做法的主要問題是，字符串異常消息無法進行進一步的處理，因而只能直接顯示給最終用戶，這一方面限制了錯誤顯示的格式和方式，另一方面也不利于程序的多語言支持。
     witrix平臺中拋出異常的標準方法為
 throw Exceptions.code(errorCode).param(paramValue).param(paramName,paramValue);
例如
    throw Exceptions.code("web.CAN_err_missing_object_in_manager").param(objectName).param(objectManager);

class Exceptions{
    public static CommonException code(String errorCode){
  return new CommonException(code);
 }
}

class CommonException extends RuntimeException{
 public CommonException param(Object paramValue){
  ...
  return this;
 }
}
      Exceptions規定只使用規范格式的錯誤碼而不是任意格式的異常消息。這樣在捕獲異常之后，就可以根據錯誤碼和當時的語言Locale設置來決定最終顯示的消息格式。
      同時CommonException采用流式設計來支持任意數量的自定義參數。這一方面減少了自定義異常類的需求，另一方面也避免了將參數與錯誤碼混合的傾向，即我們就不會傾向于
使用 throw Exceptions.code("the object manager does not contains the object :" + objectName);