Service層的異常處理

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

但歸根到底這問(wèn)題“正確”解決方法總是要以某種形式提示用戶。而提示用戶是某種前端工作，就要看界面是app，H5+AJAX還是類似于[jsp]的服務(wù)器產(chǎn)生界面。不管啥，你要根據(jù)需求去”設(shè)計(jì)一個(gè)修復(fù)錯(cuò)誤“的流程。如一個(gè)常見(jiàn)的流程要后端拋異常，然后一路到某個(gè)集中處理錯(cuò)誤的代碼，將其轉(zhuǎn)換為某個(gè)HTTP的錯(cuò)誤（業(yè)務(wù)錯(cuò)誤碼）提供給前端，前端再映射做”提示“。如用戶輸入非法請(qǐng)求，從邏輯上后端都沒(méi)法自己修復(fù)，這是個(gè)“正確”的策略。

2 報(bào)500了嘞！

如用戶上傳一個(gè)頭像，后端將圖片發(fā)給[云存儲(chǔ)]，結(jié)果云存儲(chǔ)報(bào)500，咋辦？你可能想重試，因?yàn)橐苍S僅是[網(wǎng)絡(luò)抖動(dòng)]，重試就能正常執(zhí)行。但若重試多次無(wú)效，若設(shè)計(jì)了某種熱備方案，可能改為發(fā)到另一個(gè)服務(wù)器。“重試”和“使用備份的依賴”都是“立刻處理“。

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

3 NPE了！

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

要不就是程序員想表達(dá)一個(gè)東西”沒(méi)有“，結(jié)果在后續(xù)處理中忘判斷是否為null

要不就是在寫(xiě)代碼時(shí)覺(jué)得100%不可能為null的地方出現(xiàn)了一個(gè)null

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

4 OOM了！

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

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

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

5 提升維度

一個(gè)工作線程的“外部容器“是管理工作線程的“master”

一個(gè)網(wǎng)絡(luò)請(qǐng)求的“外部容器”是一個(gè)Web Server

一個(gè)用戶進(jìn)程的“外部容器”是[操作系統(tǒng)]

Erlang把這種supervisor-worker的機(jī)制融入到語(yǔ)言的設(shè)計(jì)

Web程序很大程度能把異常拋給頂層，是因?yàn)椋?/p>

請(qǐng)求來(lái)自前端，對(duì)因?yàn)橛脩粽?qǐng)求有誤（數(shù)據(jù)合法性、權(quán)限、用戶上下文狀態(tài)）造成的問(wèn)題，最終基本只能告訴用戶。因此拋異常到一個(gè)集中處理錯(cuò)誤的地方，把異常轉(zhuǎn)換為某個(gè)業(yè)務(wù)錯(cuò)誤碼的方法，合理

后端服務(wù)一般無(wú)狀態(tài)。這也是軟件系統(tǒng)設(shè)計(jì)的一般原則。無(wú)狀態(tài)才意味著可隨時(shí)隨地安心重啟。用戶數(shù)據(jù)不會(huì)因?yàn)橐驗(yàn)橄乱粭l而會(huì)出問(wèn)題

后端對(duì)數(shù)據(jù)的修改依賴DB的事務(wù)。因此一個(gè)改一半的、沒(méi)提交的事務(wù)不會(huì)造成副作用。

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

一些處理邏輯并非無(wú)狀態(tài)

也并非所有的數(shù)據(jù)修改都能用一個(gè)事務(wù)保護(hù)

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

6 難以排查的代碼段

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

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

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

7 更難搞定的代碼段

//controller
voidcontrollerMethod(/*參數(shù)*/){
try{
returnsvc.doWorkAndGetResult(/*參數(shù)*/);
}catch(Exceptione){
returnErrorJsonObject.of(e);
}
}

//svc
voiddoWorkAndGetResult(/*someparams*/){
intres1=otherSvc1.doStep1(/*someparams*/);
this.status1+=res1;
intres2=otherSvc2.doStep2(/*someparams*/);
this.status2+=res2;
intres3=otherSvc3.doStep3(/*someparams*/);
this.status3=status1+status2+res3;
returnSomeResult.of(this.status1,this.status2,this.status3);
}

難搞在于你寫(xiě)的時(shí)候可能以為doStep1～3這種東西即使拋異常也能被Controller里的catch。

在svc這層是不用處理任何異常，「因此不寫(xiě)[try……catch]天經(jīng)地義」 。但實(shí)際上doStep1、doStep2、doStep3任何一個(gè)拋異常都會(huì)造成svc的數(shù)據(jù)狀態(tài)不一致。甚至你一開(kāi)始都可以通過(guò)文檔或其他溝通確定doStep1、doStep2、doStep3一開(kāi)始都是必然可成功，不會(huì)拋錯(cuò)的，因此你寫(xiě)的代碼一開(kāi)始是對(duì)的。

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

voiddoWorkAndGetResult(/*someparams*/){
try{
intres1=otherSvc1.doStep1(/*someparams*/);
this.status1+=res1;
intres2=otherSvc2.doStep2(/*someparams*/);
this.status2+=res2;
intres3=otherSvc3.doStep3(/*someparams*/);
this.status3=status1+status2+res3;
returnSomeResult.of(this.status1,this.status2,this.status3);
}catch(Exceptione){
//dorollback
}
}

你以為這樣就會(huì)處理好數(shù)據(jù)rollback，甚至「覺(jué)得這種代碼優(yōu)雅」 。但實(shí)際上doStep1～3每一個(gè)地方拋錯(cuò)，rollback的代碼都不一樣。

得這么寫(xiě)

voiddoWorkAndGetResult(/*someparams*/){
intres1,res2,res3;
try{
res1=otherSvc1.doStep1(/*someparams*/);
this.status1+=res1;
}catch(Exceptione){
throwe;
}

try{
res2=otherSvc2.doStep2(/*someparams*/);
this.status2+=res2;
}catch(Exceptione){
//rollbackstatus1
this.status1-=res1;
throwe;
}

try{
res3=otherSvc3.doStep3(/*someparams*/);
this.status3=status1+status2+res3;
}catch(Exceptione){
//rollbackstatus1&status2
this.status1-=res1;
this.status2-=res2;
throwe;
}
}

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

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

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

8 總結(jié)

希望程序員們對(duì)錯(cuò)誤處理都要有敬畏之心。Java因?yàn)镃hecked Exception設(shè)計(jì)問(wèn)題不得不避免使用，而Uncaughted Exception「實(shí)在是太過(guò)于弱雞，是不能給程序員提供更好地幫助的」 。

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

這個(gè)錯(cuò)誤的處理是正確的嗎？

會(huì)讓用戶看到什么？

會(huì)不會(huì)搞亂數(shù)據(jù)？

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