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

JavaWeb中 Service 層異常會怎么處理？這是個非常有啟發(fā)意義的問題。

一般初學(xué)者學(xué)習(xí)編碼和錯誤處理時，先知道編程語言有一種處理錯誤的形式或者約定（如Java就是拋異常），然后就開始用這些工具，但是卻反過來忽視這個問題的本質(zhì)：

處理錯誤是為了寫出正確的程序

到底怎么算“正確”呢？是要由解決的問題決定的。問題不同，解決方案就不同。

比如，一個web接口接受用戶的請求，這個請求需要傳入一個參數(shù)“年齡”，也許業(yè)務(wù)要求這個字段應(yīng)該是個0～150之間的整數(shù)。如果用戶輸入的是個字符串或者負(fù)數(shù)就肯定不被接受。一般在后端的某個地方都會做輸入的合法性檢查，檢查不過就拋異常。但是歸根到底這個問題的“正確”解決方法總是要以某種形式提示用戶。而提示用戶是某種前端工作，這就要看這個界面到底是app，H5 + ajax還是類似于jsp那樣的服務(wù)器產(chǎn)生的界面。不管哪種，你需要根據(jù)需求去”設(shè)計一個修復(fù)錯誤“的流程。比如一個常見的流程需要后端拋異常，然后一路到某個集中處理錯誤的代碼，將其轉(zhuǎn)換為某個HTTP的錯誤（某個特定業(yè)務(wù)錯誤碼）提供給前端，前端再去做”提示“。如果用戶輸入了非法的請求，從邏輯上后端都沒法自己修復(fù)，這是個“正確”的策略。

換一個例子，比如用戶想上傳一個頭像，后端將圖片發(fā)給某個云存儲，結(jié)果云存儲報500錯誤。怎么辦呢？你可能想到了重試幾次，因?yàn)橐苍S問題僅僅是臨時的網(wǎng)絡(luò)抖動而已，重試就可以正常執(zhí)行。但如果重試多次無效。如果做系統(tǒng)時設(shè)計了某種熱備方案，那么就可能改為發(fā)到另外一個服務(wù)器上?！爸卦嚒焙汀笆褂脗浞莸囊蕾嚒倍际恰傲⒖烫幚怼?。

（推薦教程：Java教程）

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

另外一個例子，你的程序拋了一個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，把問題報警出來。而不是等到用戶找客服來吐槽。

再換一個例子，比如你的后端程序突然OOM，掛了。掛的程序是沒法恢復(fù)自己的。要做到“正確”就必須得在服務(wù)之外的容器考慮這個問題。比如你的服務(wù)跑在k8s上，他們會監(jiān)控你程序的狀態(tài)，然后重新啟動新的服務(wù)實(shí)例以彌補(bǔ)掛掉的服務(wù)，還得調(diào)整流量，把去往掛掉服務(wù)的流量切掉，重新?lián)Q到新的實(shí)例上。這里的恢復(fù)因?yàn)榭缦到y(tǒng)所以不能僅僅用異常實(shí)現(xiàn)，但是道理是一樣的。但光靠重啟就是“正確”的嗎？如果服務(wù)是完全無狀態(tài)的，問題不大。但是如果是有狀態(tài)的，部分用戶數(shù)據(jù)可能就會被執(zhí)行一半的請求搞亂套。因此重啟時要留意先“恢復(fù)數(shù)據(jù)到合法狀態(tài)”。這又回到了你需要知道怎么樣才是“正確”的做法。只依靠簡單的語法功能是不能無腦解決這個事的。

• 我們可以推廣下，一個工作線程的“外部容器“是管理工作線程的“master”。一個網(wǎng)絡(luò)請求的“外部容器”是一個web server。一個用戶進(jìn)程的“外部容器”是操作系統(tǒng)。Erlang把這種supervisor-worker的機(jī)制融入到語言的設(shè)計中。

（推薦微課：Java微課）

Web程序之所以很大程度上能夠把異常拋給頂層，主要由于3個原因：

• 請求來自于前端，對于因?yàn)橛脩粽埱笥姓`（數(shù)據(jù)合法性、權(quán)限、用戶上下文狀態(tài)）造成的問題，最終大概率只能告訴用戶。因此拋異常到一個集中處理錯誤的地方，把異常轉(zhuǎn)換為某個業(yè)務(wù)錯誤碼的方法是合理的。
• 后端服務(wù)一般都是無狀態(tài)的。這也是互聯(lián)網(wǎng)系統(tǒng)設(shè)計的一般性原則。無狀態(tài)就意味著可以隨意重啟。對于用戶的數(shù)據(jù)因?yàn)橄乱粭l一般情況下不會出問題。
• 后端對數(shù)據(jù)的修改依賴DB的事務(wù)。因此一個改了一半的沒提交的事務(wù)是不會造成副副作用。

但你要清楚上面這3條并不是總是成立的?？倳嬖谝恍┨幚磉壿嫴⒎峭耆珶o狀態(tài)，也并不是所有的數(shù)據(jù)修改都能用一個事務(wù)保護(hù)。尤其要注意對微服務(wù)的調(diào)用，對內(nèi)存狀態(tài)的修改是沒有事務(wù)保護(hù)的，一不留神就會出現(xiàn)搞亂用戶數(shù)據(jù)的問題。比如：

 try {
   int res1 = doStep1();
   this.statusVar1 += res1;
   int res2 = doStep2();
   this.statusVar2 += res2;
   int res3 = doStep3(); // throw an exception
   this.statusVar3 = statusVar1 + statusVar2 + res3;
} catch ( ...) { 
   // ...
}

先假設(shè)this.statusVar1, this.statusVar2, this.statusVar3之間需要維護(hù)某種不變的約束（invariant）。然后執(zhí)行這段代碼時，如果在doStep3那拋出一個異常下面對statusVar3的賦值就不會執(zhí)行。這時如果不能將statusVar1和statusVar2的修改rollback回去，就會造成數(shù)據(jù)違反約束的問題。而程序員一般是很難直接發(fā)現(xiàn)這個數(shù)據(jù)被改壞了。而壞掉的數(shù)據(jù)可能會偷偷的導(dǎo)致其他依賴這個數(shù)據(jù)的代碼邏輯出錯（比如原本應(yīng)該給積分的，結(jié)果卻沒給）。而這種錯誤一般非常難調(diào)查，從大量數(shù)據(jù)里找到不正確的那一小撮是相當(dāng)困難的事。

比起上面這段更難搞得定的是這樣的代碼：

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


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

這段代碼的可怕之處在于，你在寫的時候可能會以為doStep1～3這種東西即使拋異常，也能被Controller里的catch。在svc這層是不用處理任何異常的，因此不寫try……catch是天經(jīng)地義的。但實(shí)際上doStep1、doStep2、doStep3任何一個拋異常都會造成svc的數(shù)據(jù)狀態(tài)不一致。甚至你一開始都可以通過文檔或者其他溝通方式確定doStep1、doStep2、doStep3一開始都是必然可以成功，不會拋錯的，因此你寫的代碼一開始是對的。但是你可能無法控制他們的實(shí)現(xiàn)（比如他們是另外一個團(tuán)隊(duì)開發(fā)的lib提供的），而他們的實(shí)現(xiàn)可能會改成會拋錯。你的代碼可能在完全不自知的情況下從“不會出問題”變成了“可能出問題”…… 更可怕的是類似于這樣的代碼是不能正確工作的：

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

你可能以為這樣就會處理好數(shù)據(jù)rollback了，甚至你會覺得這種代碼非常優(yōu)雅。但是實(shí)際上doStep1～3每一個地方拋錯，rollback的代碼都不一樣。你必須得這么寫：

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


    try {
      res2 = otherSvc2.doStep2(/* some params */);
      this.statusVar2 += res2;
    } catch (Exception e) {
      // rollback statusVar1
      this.statusVar1 -= res1;
      throw e;
    }

  
    try {
      res3 = otherSvc3.doStep3(/* some params */);
      this.statusVar3 = statusVar1 + statusVar2 + res3;
    } catch (Exception e) {
      // rollback statusVar1 & statusVar2
      this.statusVar1 -= res1;
      this.statusVar2 -= res2;
      throw e;
   } 
}

這才是能得到正確結(jié)果的代碼——在任何地方出現(xiàn)錯誤都能維護(hù)數(shù)據(jù)一致性。優(yōu)雅嗎？看起來很丑。這甚至比go的if err != nil還丑。但如果一定要在正確性和優(yōu)雅性上作出取舍，我會毫不猶豫的選擇前者。作為程序員是不能直接認(rèn)為拋異?？梢越鉀Q任何問題的，你必須學(xué)會寫出有正確邏輯的程序，哪怕很難，并且看起來很丑。為了達(dá)成很高的正確性，你不能總是把自己大部分注意力放在“一切都OK的流程上“，而把錯誤看作是可以隨便搞一下的工作，或者簡單的相信exception可以自動搞定一切。

總結(jié)一下，我希望所有程序員對錯誤處理都要有起碼的敬畏之心。Java這邊因?yàn)?code>Checked Exception的設(shè)計問題不得不避免使用（見大寬寬 - Java設(shè)計出checked exception有必要嗎？），而Uncaughted Exception實(shí)在是太過于弱雞，是不能給程序員提供更好地幫助的。

因此，程序員在每次拋錯或者處理錯誤的時候都要對自己靈魂三擊：這個錯誤的處理是正確的嗎？會讓用戶看到什么？會不會搞亂數(shù)據(jù)？不要以為自己拋了個異常就不管了。

此外，在編譯器不能幫上太多忙的時候，好好寫UT來保護(hù)代碼脆弱的正確性。

以上就是w3cschool分享的JavaWeb 中 Service 層異常拋到 Controller 層處理還是直接處理。希望對大家有所幫助。