1 前言

一般初學(xué)者學(xué)習(xí)編碼和 錯誤處理 時，先知道 編程語言 有一種處理錯誤的形式或約定（如Java就拋異常），然后就開始用這些工具。但卻忽視這問題本質(zhì)：處理錯誤是為了寫正確程序?？墒?/p>

2 啥叫“正確”？

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

如一個web接口接受用戶請求，參數(shù)age，也許業(yè)務(wù)要求字段是0～150之間整數(shù)。如輸入字符串或負(fù)數(shù)就肯定不接受。一般在后端某地做輸入合法性檢查，不過就拋異常。

但歸根到底這問題“正確”解決方法總是要以某種形式提示用戶。而提示用戶是某種前端工作，就要看界面是app，H5+AJAX還是類似于[jsp]的服務(wù)器產(chǎn)生界面。不管啥，你要根據(jù)需求去”設(shè)計一個修復(fù)錯誤“的流程。

如一個常見的流程要后端拋異常，然后一路到某個集中處理錯誤的代碼，將其轉(zhuǎn)換為某個HTTP的錯誤（業(yè)務(wù)錯誤碼）提供給前端，前端再映射做”提示“。如用戶輸入非法請求，從邏輯上后端都沒法自己修復(fù)，這是個“正確”的策略。

3 報500了嘞！

如用戶上傳一個頭像，后端將圖片發(fā)給[云存儲]，結(jié)果云存儲報500，咋辦？你可能想重試，因為也許僅是[網(wǎng)絡(luò)抖動]，重試就能正常執(zhí)行。但若重試多次無效，若設(shè)計了某種熱備方案，可能改為發(fā)到另一個服務(wù)器?！爸卦嚒焙汀笆褂脗浞莸囊蕾嚒倍际恰傲⒖烫幚怼?。

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

4 NPE了！

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

• 要不就是程序員想表達(dá)一個東西”沒有“，結(jié)果在后續(xù)處理中忘判斷是否為null
• 要不就是在寫代碼時覺得100%不可能為null的地方出現(xiàn)了一個null

不管哪種，這錯誤用戶總會看到一個很含糊的報錯信息，這遠(yuǎn)遠(yuǎn)不夠。“正確”辦法是程序員自己能盡快發(fā)現(xiàn)它，并盡快修復(fù)。要做到這點(diǎn)，需要[監(jiān)控系統(tǒng)]不斷爬log，把問題報警出來。而非等用戶找客服投訴。

5 OOM了！

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

如你的服務(wù)跑在[k8s]，他們會監(jiān)控你程序狀態(tài)，然后重啟新的服務(wù)實例彌補(bǔ)掛掉的服務(wù)，還得調(diào)整流量，把去往宕機(jī)服務(wù)的流量切換到新實例。這的恢復(fù)因為跨系統(tǒng)所以不能僅用異常實現(xiàn)，但道理一樣。

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

6 提升維度

• 一個工作線程的“外部容器“是管理工作線程的“master”
• 一個網(wǎng)絡(luò)請求的“外部容器”是一個Web Server
• 一個用戶進(jìn)程的“外部容器”是[操作系統(tǒng)]
• Erlang把這種supervisor-worker的機(jī)制融入到語言的設(shè)計

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

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

但這3條件并非總成立?？偰苡龅剑?/span>

• 一些處理邏輯并非無狀態(tài)
• 也并非所有的數(shù)據(jù)修改都能用一個事務(wù)保護(hù)

尤其要注意對[微服務(wù)]的調(diào)用，對內(nèi)存狀態(tài)「的修改是沒有事務(wù)保護(hù)的」，一不留神就會搞亂用戶數(shù)據(jù)。比如下面代碼段

7 難以排查的代碼段

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

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

而程序員很難發(fā)現(xiàn)這個數(shù)據(jù)被改壞了。壞數(shù)據(jù)還可能導(dǎo)致其他依賴這數(shù)據(jù)的代碼邏輯出錯（如原本應(yīng)該給積分的，卻沒給）。而這種錯誤一般很難排查，從大量數(shù)據(jù)里找到不正確的那一小段何其困難。

8 更難搞定的代碼段

// controller    
void controllerMethod(/* 參數(shù) */) {    
  try {    
    return svc.doWorkAndGetResult(/* 參數(shù) */);    
  } 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]天經(jīng)地義。但實際上doStep1、doStep2、doStep3任何一個拋異常都會造成svc的數(shù)據(jù)狀態(tài)不一致。甚至你一開始都可以通過文檔或其他溝通確定doStep1、doStep2、doStep3一開始都是必然可成功，不會拋錯的，因此你寫的代碼一開始是對的。

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

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    
   }    
}

你以為這樣就會處理好數(shù)據(jù)rollback，甚至「覺得這種代碼優(yōu)雅」。但實際上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;    
   }     
}

這才是得到正確結(jié)果的代碼，在任何地方出錯都能維護(hù)數(shù)據(jù)一致性。優(yōu)雅嗎？

看起來很丑。比go的if err != nil還丑。但要在正確性和優(yōu)雅性取舍，肯定毫不猶豫選前者。作為程序員不能直接認(rèn)為拋異?？山鉀Q任何問題，須學(xué)會寫出有正確邏輯的程序，哪怕很難且看起來丑。

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

9總結(jié)

希望程序員們對錯誤處理都要有敬畏之心。Java因為Checked Exception設(shè)計問題不得不避免使用，而Uncaughted Exception實在是太過于弱雞，是不能給程序員提供更好地幫助的。

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

• 這個錯誤的處理是正確的嗎？
• 會讓用戶看到什么？
• 會不會搞亂數(shù)據(jù)？

不要以為自己拋了個異常就不管了。在[編譯器]不能幫上太多忙的時候，好好寫UT來保護(hù)代碼脆弱的正確性。

為人為己，請多寫正確的代碼。