Service 層異常拋到 Controller 層處理還是直接處理？

0 前言一般初學者學習編碼和[錯誤處理]時，先知道[編程語言]有一種處理錯誤的形式或約定（如Java就拋異常），然後就開始用這些工具。但卻忽視這問題本質：處理錯誤是為了寫正確程式。可是 1 啥叫“正確”？由解決的問題決定的。問題不同，解決方案不同。如一個web介面接受用戶請求，參數age，也許 ...

0 前言

一般初學者學習編碼和[錯誤處理]時，先知道[編程語言]有一種處理錯誤的形式或約定（如Java就拋異常），然後就開始用這些工具。但卻忽視這問題本質：處理錯誤是為了寫正確程式。可是

1 啥叫“正確”？

由解決的問題決定的。問題不同，解決方案不同。

如一個web介面接受用戶請求，參數age，也許業務要求欄位是0～150之間整數。如輸入字元串或負數就肯定不接受。一般在後端某地做輸入合法性檢查，不過就拋異常。

但歸根到底這問題“正確”解決方法總是要以某種形式提示用戶。而提示用戶是某種前端工作，就要看界面是app，H5+AJAX還是類似於[jsp]的伺服器產生界面。不管啥，你要根據需求去”設計一個修複錯誤“的流程。如一個常見的流程要後端拋異常，然後一路到某個集中處理錯誤的代碼，將其轉換為某個HTTP的錯誤（業務錯誤碼）提供給前端，前端再映射做”提示“。如用戶輸入非法請求，從邏輯上後端都沒法自己修複，這是個“正確”的策略。

2 報500了嘞！

如用戶上傳一個頭像，後端將圖片發給[雲存儲]，結果雲存儲報500，咋辦？你可能想重試，因為也許僅是[網路抖動]，重試就能正常執行。但若重試多次無效，若設計了某種熱備方案，可能改為發到另一個伺服器。“重試”和“使用備份的依賴”都是“立刻處理“。

但若重試無效，所有的[備份服務]也無效，也許就能像上面那樣把錯誤拋給前端，提示用戶“伺服器開小差”。從這方案易看出，你想把錯誤拋到哪裡是因為那個catch的地方是處理問題最方便的地方。一個問題的解決方案可能要幾個不同的錯誤處理組合起來才能辦到。

3 NPE了！

你的程式拋個NPE。這一般就是程式員的bug：

要不就是程式員想表達一個東西”沒有“，結果在後續處理中忘判斷是否為null
要不就是在寫代碼時覺得100%不可能為null的地方出現了一個null

不管哪種，這錯誤用戶總會看到一個很含糊的報錯信息，這遠遠不夠。“正確”辦法是程式員自己能儘快發現它，並儘快修複。要做到這點，需要[監控系統]不斷爬log，把問題報警出來。而非等用戶找客服投訴。

4 OOM了！

比如你的[後端程式]突然OOM掛了。掛的程式沒法恢復自己。要做到“正確”，須在服務之外的容器考慮這問題。

如你的服務跑在[k8s]，他們會監控你程式狀態，然後重啟新的服務實例彌補掛掉的服務，還得調整流量，把去往宕機服務的流量切換到新實例。這的恢復因為跨系統所以不能僅用異常實現，但道理一樣。

但光靠重啟就“正確”了？若服務是完全無狀態，問題不大。但若有狀態，部分用戶數據可能被執行一半的請求搞亂。因此重啟要留意先“恢複數據到合法狀態”。這又回到你要知道咋樣才是“正確”的做法。只依靠簡單的語法功能不能無腦解決這事。

5 提升維度

一個工作線程的“外部容器“是管理工作線程的“master”
一個網路請求的“外部容器”是一個Web Server
一個用戶進程的“外部容器”是[操作系統]
Erlang把這種supervisor-worker的機制融入到語言的設計

Web程式很大程度能把異常拋給頂層，是因為：

請求來自前端，對因為用戶請求有誤（數據合法性、許可權、用戶上下文狀態）造成的問題，最終基本只能告訴用戶。因此拋異常到一個集中處理錯誤的地方，把異常轉換為某個業務錯誤碼的方法，合理
後端服務一般無狀態。這也是軟體系統設計的一般原則。無狀態才意味著可隨時隨地安心重啟。用戶數據不會因為因為下一條而會出問題
後端對數據的修改依賴DB的事務。因此一個改一半的、沒提交的事務不會造成副作用。

但這3條件並非總成立。總能遇到：

一些處理邏輯並非無狀態
也並非所有的數據修改都能用一個事務保護

尤其要註意對[微服務]的調用，對記憶體狀態的修改是沒有事務保護的，一不留神就會搞亂用戶數據。比如下麵代碼段

6 難以排查的代碼段

 try {
   int res1 = doStep1();
   this.status1 += res1;
   int res2 = doStep2();
   this.status2 += res2;
   // 拋個異常
   int res3 = doStep3();
   this.status3 = status1 + status2 + res3;
} catch ( ...) { 
   // ...
}

先假設status1、status2、status3之間需維護某種不變的約束（invariant）。然後執行這段代碼時，如在doStep3拋異常，下麵對status3的賦值就不會執行。這時如不能將status1、status2的修改rollback，就會造成數據違反約束的問題。

而程式員很難發現這個數據被改壞了。壞數據還可能導致其他依賴這數據的代碼邏輯出錯（如原本應該給積分的，卻沒給）。而這種錯誤一般很難排查，從大量數據里找到不正確的那一小段何其困難。

7 更難搞定的代碼段

// controller
void controllerMethod(/* 參數 */) {
  try {
    return svc.doWorkAndGetResult(/* 參數 */);
  } catch (Exception e) {
    return ErrorJsonObject.of(e);
  }
}

// svc
void doWorkAndGetResult(/* some params*/) {
    int res1 = otherSvc1.doStep1(/* some params */);
    this.status1 += res1;
    int res2 = otherSvc2.doStep2(/* some params */);
    this.status2 += res2;
    int res3 = otherSvc3.doStep3(/* some params */);
    this.status3 = status1 + status2 + res3;
    return SomeResult.of(this.status1, this.status2, this.status3);
}

難搞在於你寫的時候可能以為doStep1～3這種東西即使拋異常也能被Controller里的catch。

在svc這層是不用處理任何異常，因此不寫[try……catch]天經地義。但實際上doStep1、doStep2、doStep3任何一個拋異常都會造成svc的數據狀態不一致。甚至你一開始都可以通過文檔或其他溝通確定doStep1、doStep2、doStep3一開始都是必然可成功，不會拋錯的，因此你寫的代碼一開始是對的。

但你可能無法控制他們的實現（如他們是另外一個團隊開發的[jar]提供的），而他們的實現可能會改成拋錯。你的代碼可能在完全不自知情況下從“不會出問題”變成“可能出問題”…… 更可怕的類似代碼不能正確工作：

void doWorkAndGetResult(/* some params*/) {
    try {
       int res1 = otherSvc1.doStep1(/* some params */);
       this.status1 += res1;
       int res2 = otherSvc2.doStep2(/* some params */);
       this.status2 += res2;
       int res3 = otherSvc3.doStep3(/* some params */);
       this.status3 = status1 + status2 + res3;
       return SomeResult.of(this.status1, this.status2, this.status3);
   } catch (Exception e) {
     // do rollback
   }
}

你以為這樣就會處理好數據rollback，甚至覺得這種代碼優雅。但實際上doStep1～3每一個地方拋錯，rollback的代碼都不一樣。

得這麼寫

void doWorkAndGetResult(/* some params*/) {
    int res1, res2, res3;
    try {
       res1 = otherSvc1.doStep1(/* some params */);
       this.status1 += res1;
    } catch (Exception e) {
       throw e;
    }

    try {
      res2 = otherSvc2.doStep2(/* some params */);
      this.status2 += res2;
    } catch (Exception e) {
      // rollback status1
      this.status1 -= res1;
      throw e;
    }
  
    try {
      res3 = otherSvc3.doStep3(/* some params */);
      this.status3 = status1 + status2 + res3;
    } catch (Exception e) {
      // rollback status1 & status2
      this.status1 -= res1;
      this.status2 -= res2;
      throw e;
   } 
}

這才是得到正確結果的代碼，在任何地方出錯都能維護數據一致性。優雅嗎？

看起來很醜。比go的if err != nil還醜。但要在正確性和優雅性取捨，肯定毫不猶豫選前者。作為程式員不能直接認為拋異常可解決任何問題，須學會寫出有正確邏輯的程式，哪怕很難且看起來醜。

為達成高正確性，你不能總將自己大部分註意力放在“一切都OK的流程“，而把錯誤看作是可隨便應付了事的工作或簡單的相信exception可自動搞定一切。

8 總結

對錯誤處理要有敬畏之心：

Java因為Checked Exception設計問題不得不避免使用
而Uncaughted Exception實在弱雞，不能給程式員提供更好幫助

因此，程式員在每次拋錯或者處理錯誤的時候都要三省吾身：

這個錯誤的處理是正確嗎？
會讓用戶看到啥？
會不會搞亂數據？

不要以為自己拋個異常就完事了。在[編譯器]不能幫上太多忙時，好好寫UT來保護代碼可憐的正確性。

請多寫正確的代碼！

本文由博客一文多發平臺 OpenWrite 發佈！