Golang 中的 io 包詳解：組合接口
io.ReadWriter// ReadWriter is the interface that groups the basic Read and Write methods.type ReadWriter interface { Reader Writer}是對Reader和Writer接口的組合，
一般初學者學習編碼和 錯誤處理 時，先知道 編程語言 有一種處理錯誤的形式或約定（如Java就拋異常），然后就開始用這些工具。但卻忽視這問題本質：處理錯誤是為了寫正確程序。可是
由解決的問題決定的。問題不同，解決方案不同。
如一個web接口接受用戶請求，參數age，也許業務要求字段是0～150之間整數。如輸入字符串或負數就肯定不接受。一般在后端某地做輸入合法性檢查，不過就拋異常。
但歸根到底這問題“正確”解決方法總是要以某種形式提示用戶。而提示用戶是某種前端工作，就要看界面是app，H5+AJAX還是類似于[jsp]的服務器產生界面。不管啥，你要根據需求去”設計一個修復錯誤“的流程。
如一個常見的流程要后端拋異常，然后一路到某個集中處理錯誤的代碼，將其轉換為某個HTTP的錯誤（業務錯誤碼）提供給前端，前端再映射做”提示“。如用戶輸入非法請求，從邏輯上后端都沒法自己修復，這是個“正確”的策略。
如用戶上傳一個頭像，后端將圖片發給[云存儲]，結果云存儲報500，咋辦？你可能想重試，因為也許僅是[網絡抖動]，重試就能正常執行。但若重試多次無效，若設計了某種熱備方案，可能改為發到另一個服務器?！爸卦嚒焙汀笆褂脗浞莸囊蕾嚒倍际恰傲⒖烫幚怼?。
但若重試無效，所有的[備份服務]也無效，也許就能像上面那樣把錯誤拋給前端，提示用戶“服務器開小差”。從這方案易看出，你想把錯誤拋到哪里是因為那個catch的地方是處理問題最方便的地方。一個問題的解決方案可能要幾個不同的錯誤處理組合起來才能辦到。
你的程序拋個NPE。這一般就是程序員的bug：
不管哪種，這錯誤用戶總會看到一個很含糊的報錯信息，這遠遠不夠?！罢_”辦法是程序員自己能盡快發現它，并盡快修復。要做到這點，需要[監控系統]不斷爬log，把問題報警出來。而非等用戶找客服投訴。
比如你的[后端程序]突然OOM掛了。掛的程序沒法恢復自己。要做到“正確”，須在服務之外的容器考慮這問題。
如你的服務跑在[k8s]，他們會監控你程序狀態，然后重啟新的服務實例彌補掛掉的服務，還得調整流量，把去往宕機服務的流量切換到新實例。這的恢復因為跨系統所以不能僅用異常實現，但道理一樣。
但光靠重啟就“正確”了？若服務是完全無狀態，問題不大。但若有狀態，部分用戶數據可能被執行一半的請求搞亂。因此重啟要留意先“恢復數據到合法狀態”。這又回到你要知道咋樣才是“正確”的做法。只依靠簡單的語法功能不能無腦解決這事。
Web程序很大程度能把異常拋給頂層，是因為：
但這3條件并非總成立?？偰苡龅剑?/span>
尤其要注意對[微服務]的調用，對內存狀態「的修改是沒有事務保護的」，一不留神就會搞亂用戶數據。比如下面代碼段
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，就會造成數據違反約束的問題。
而程序員很難發現這個數據被改壞了。壞數據還可能導致其他依賴這數據的代碼邏輯出錯（如原本應該給積分的，卻沒給）。而這種錯誤一般很難排查，從大量數據里找到不正確的那一小段何其困難。
// 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還丑。但要在正確性和優雅性取舍，肯定毫不猶豫選前者。作為程序員不能直接認為拋異?？山鉀Q任何問題，須學會寫出有正確邏輯的程序，哪怕很難且看起來丑。
為達成高正確性，你不能總將自己大部分注意力放在“一切都OK的流程“，而把錯誤看作是可隨便應付了事的工作或簡單的相信exception可自動搞定一切。
希望程序員們對錯誤處理都要有敬畏之心。Java因為Checked Exception設計問題不得不避免使用，而Uncaughted Exception實在是太過于弱雞，是不能給程序員提供更好地幫助的。
因此，程序員在每次拋錯或者處理錯誤的時候都要三省吾身：
不要以為自己拋了個異常就不管了。在[編譯器]不能幫上太多忙的時候，好好寫UT來保護代碼脆弱的正確性。
為人為己，請多寫正確的代碼。
本文鏈接：http://www.tebozhan.com/showinfo-26-43294-0.htmlService 層的異常是拋到 Controller 層還是直接處理？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 使用Linux命令行傳遞環境變量給Docker容器
下一篇： 深入學習 C++，內存管理
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號