把錯(cuò)誤分成兩大類很有用[腳注3]：
* **操作失敗**?是正確編寫的程序在運(yùn)行時(shí)產(chǎn)生的錯(cuò)誤。它并不是程序的Bug，反而經(jīng)常是其它問題：系統(tǒng)本身（內(nèi)存不足或者打開文件數(shù)過多），系統(tǒng)配置（沒有到達(dá)遠(yuǎn)程主機(jī)的路由），網(wǎng)絡(luò)問題（端口掛起），遠(yuǎn)程服務(wù)（500錯(cuò)誤，連接失?。?。例子如下：
* 連接不到服務(wù)器
* 無法解析主機(jī)名
* 無效的用戶輸入
* 請(qǐng)求超時(shí)
* 服務(wù)器返回500
* 套接字被掛起
* 系統(tǒng)內(nèi)存不足
* **程序員失誤**?是程序里的Bug。這些錯(cuò)誤往往可以通過修改代碼避免。它們永遠(yuǎn)都沒法被有效的處理。
* 讀取 undefined 的一個(gè)屬性
* 調(diào)用異步函數(shù)沒有指定回調(diào)
* 該傳對(duì)象的時(shí)候傳了一個(gè)字符串
* 該傳IP地址的時(shí)候傳了一個(gè)對(duì)象
人們把操作失敗和程序員的失誤都稱為“錯(cuò)誤”，但其實(shí)它們很不一樣。操作失敗是所有正確的程序應(yīng)該處理的錯(cuò)誤情形，只要被妥善處理它們不一定會(huì)預(yù)示著Bug或是嚴(yán)重的問題?！拔募也坏健笔且粋€(gè)操作失敗，但是它并不一定意味著哪里出錯(cuò)了。它可能只是代表著程序如果想用一個(gè)文件得事先創(chuàng)建它。
與之相反，程序員失誤是徹徹底底的Bug。這些情形下你會(huì)犯錯(cuò)：忘記驗(yàn)證用戶輸入，敲錯(cuò)了變量名，諸如此類。這樣的錯(cuò)誤根本就沒法被處理，如果可以，那就意味著你用處理錯(cuò)誤的代碼代替了出錯(cuò)的代碼。
這樣的區(qū)分很重要：操作失敗是程序正常操作的一部分。而由程序員的失誤則是Bug。
有的時(shí)候，你會(huì)在一個(gè)Root問題里同時(shí)遇到操作失敗和程序員的失誤。HTTP服務(wù)器訪問了未定義的變量時(shí)奔潰了，這是程序員的失誤。當(dāng)前連接著的客戶端會(huì)在程序崩潰的同時(shí)看到一個(gè)`ECONNRESET`錯(cuò)誤，在NodeJS里通常會(huì)被報(bào)成“Socket Hang-up”。對(duì)客戶端來說，這是一個(gè)不相關(guān)的操作失敗, 那是因?yàn)檎_的客戶端必須處理服務(wù)器宕機(jī)或者網(wǎng)絡(luò)中斷的情況。
類似的，如果不處理好操作失敗, 這本身就是一個(gè)失誤。舉個(gè)例子，如果程序想要連接服務(wù)器，但是得到一個(gè)`ECONNREFUSED`錯(cuò)誤，而這個(gè)程序沒有監(jiān)聽套接字上的?`error`事件,然后程序崩潰了，這是程序員的失誤。連接斷開是操作失敗（因?yàn)檫@是任何一個(gè)正確的程序在系統(tǒng)的網(wǎng)絡(luò)或者其它模塊出問題時(shí)都會(huì)經(jīng)歷的），如果它不被正確處理，那它就是一個(gè)失誤。
理解操作失敗和程序員失誤的不同, 是搞清怎么傳遞異常和處理異常的基礎(chǔ)。明白了這點(diǎn)再繼續(xù)往下讀。
### 處理操作失敗
就像性能和安全問題一樣，錯(cuò)誤處理并不是可以憑空加到一個(gè)沒有任何錯(cuò)誤處理的程序中的。你沒有辦法在一個(gè)集中的地方處理所有的異常，就像你不能在一個(gè)集中的地方解決所有的性能問題。你得考慮任何會(huì)導(dǎo)致失敗的代碼（比如打開文件，連接服務(wù)器，F(xiàn)ork子進(jìn)程等）可能產(chǎn)生的結(jié)果。包括為什么出錯(cuò)，錯(cuò)誤背后的原因。之后會(huì)提及，但是關(guān)鍵在于錯(cuò)誤處理的粒度要細(xì)，因?yàn)槟睦锍鲥e(cuò)和為什么出錯(cuò)決定了影響大小和對(duì)策。
你可能會(huì)發(fā)現(xiàn)在棧的某幾層不斷地處理相同的錯(cuò)誤。這是因?yàn)榈讓映讼蛏蠈觽鬟f錯(cuò)誤，上層再向它的上層傳遞錯(cuò)誤以外，底層沒有做任何有意義的事情。通常，只有頂層的調(diào)用者知道正確的應(yīng)對(duì)是什么，是重試操作，報(bào)告給用戶還是其它。但是那并不意味著，你應(yīng)該把所有的錯(cuò)誤全都丟給頂層的回調(diào)函數(shù)。因?yàn)?，頂層的回調(diào)函數(shù)不知道發(fā)生錯(cuò)誤的上下文，不知道哪些操作已經(jīng)成功執(zhí)行，哪些操作實(shí)際上失敗了。
我們來更具體一些。對(duì)于一個(gè)給定的錯(cuò)誤，你可以做這些事情:
* **直接處理**。有的時(shí)候該做什么很清楚。如果你在嘗試打開日志文件的時(shí)候得到了一個(gè)`ENOENT`錯(cuò)誤，很有可能你是第一次打開這個(gè)文件，你要做的就是首先創(chuàng)建它。更有意思的例子是，你維護(hù)著到服務(wù)器（比如數(shù)據(jù)庫(kù)）的持久連接，然后遇到了一個(gè)“socket hang-up”的異常。這通常意味著要么遠(yuǎn)端要么本地的網(wǎng)絡(luò)失敗了。很多時(shí)候這種錯(cuò)誤是暫時(shí)的，所以大部分情況下你得重新連接來解決問題。（這和接下來的重試不大一樣，因?yàn)樵谀愕玫竭@個(gè)錯(cuò)誤的時(shí)候不一定有操作正在進(jìn)行）
* **把出錯(cuò)擴(kuò)散到客戶端**。如果你不知道怎么處理這個(gè)異常，最簡(jiǎn)單的方式就是放棄你正在執(zhí)行的操作，清理所有開始的，然后把錯(cuò)誤傳遞給客戶端。（怎么傳遞異常是另外一回事了，接下來會(huì)討論）。這種方式適合錯(cuò)誤短時(shí)間內(nèi)無法解決的情形。比如，用戶提交了不正確的JSON，你再解析一次是沒什么幫助的。
* **重試操作**。對(duì)于那些來自網(wǎng)絡(luò)和遠(yuǎn)程服務(wù)的錯(cuò)誤，有的時(shí)候重試操作就可以解決問題。比如，遠(yuǎn)程服務(wù)返回了503（服務(wù)不可用錯(cuò)誤），你可能會(huì)在幾秒種后重試。**如果確定要重試，你應(yīng)該清晰的用文檔記錄下將會(huì)多次重試，重試多少次直到失敗,以及兩次重試的間隔。**?另外，不要每次都假設(shè)需要重試。如果在棧中很深的地方（比如，被一個(gè)客戶端調(diào)用，而那個(gè)客戶端被另外一個(gè)由用戶操作的客戶端控制），這種情形下快速失敗讓客戶端去重試會(huì)更好。如果棧中的每一層都覺得需要重試，用戶最終會(huì)等待更長(zhǎng)的時(shí)間，因?yàn)槊恳粚佣紱]有意識(shí)到下層同時(shí)也在嘗試。
* **直接崩潰**。對(duì)于那些本不可能發(fā)生的錯(cuò)誤，或者由程序員失誤導(dǎo)致的錯(cuò)誤（比如無法連接到同一程序里的本地套接字），可以記錄一個(gè)錯(cuò)誤日志然后直接崩潰。其它的比如內(nèi)存不足這種錯(cuò)誤，是JavaScript這樣的腳本語言無法處理的，崩潰是十分合理的。（即便如此，在`child_process.exec`這樣的分離的操作里，得到`ENOMEM`錯(cuò)誤，或者那些你可以合理處理的錯(cuò)誤時(shí)，你應(yīng)該考慮這么做）。在你無計(jì)可施需要讓管理員做修復(fù)的時(shí)候，你也可以直接崩潰。如果你用光了所有的文件描述符或者沒有訪問配置文件的權(quán)限，這種情況下你???么都做不了，只能等某個(gè)用戶登錄系統(tǒng)把東西修好。
* **記錄錯(cuò)誤，其他什么都不做**。有的時(shí)候你什么都做不了，沒有操作可以重試或者放棄，沒有任何理由崩潰掉應(yīng)用程序。舉個(gè)例子吧，你用DNS跟蹤了一組遠(yuǎn)程服務(wù)，結(jié)果有一個(gè)DNS失敗了。除了記錄一條日志并且繼續(xù)使用剩下的服務(wù)以外，你什么都做不了。但是，你至少得記錄點(diǎn)什么（凡事都有例外。如果這種情況每秒發(fā)生幾千次，而你又沒法處理，那每次發(fā)生都記錄可能就不值得了，但是要周期性的記錄）。
### （沒有辦法）處理程序員的失誤
對(duì)于程序員的失誤沒有什么好做的。從定義上看，一段本該工作的代碼壞掉了（比如變量名敲錯(cuò)），你不能用更多的代碼再去修復(fù)它。一旦你這樣做了，你就使用錯(cuò)誤處理的代碼代替了出錯(cuò)的代碼。
有些人贊成從程序員的失誤中恢復(fù)，也就是讓當(dāng)前的操作失敗，但是繼續(xù)處理請(qǐng)求。這種做法不推薦?？紤]這樣的情況：原始代碼里有一個(gè)失誤是沒考慮到某種特殊情況。你怎么確定這個(gè)問題不會(huì)影響其他請(qǐng)求呢？如果其它的請(qǐng)求共享了某個(gè)狀態(tài)（服務(wù)器，套接字，數(shù)據(jù)庫(kù)連接池等），有極大的可能其他請(qǐng)求會(huì)不正常。
典型的例子是REST服務(wù)器（比如用Restify搭的），如果有一個(gè)請(qǐng)求處理函數(shù)拋出了一個(gè)`ReferenceError`（比如，變量名打錯(cuò)）。繼續(xù)運(yùn)行下去很有肯能會(huì)導(dǎo)致嚴(yán)重的Bug，而且極其難發(fā)現(xiàn)。例如：
1. 一些請(qǐng)求間共享的狀態(tài)可能會(huì)被變成`null`，`undefined`或者其它無效值，結(jié)果就是下一個(gè)請(qǐng)求也失敗了。
2. 數(shù)據(jù)庫(kù)（或其它）連接可能會(huì)被泄露，降低了能夠并行處理的請(qǐng)求數(shù)量。最后只剩下幾個(gè)可用連接會(huì)很壞，將導(dǎo)致請(qǐng)求由并行變成串行被處理。
3. 更糟的是， postgres 連接會(huì)被留在打開的請(qǐng)求事務(wù)里。這會(huì)導(dǎo)致 postgres “持有”表中某一行的舊值，因?yàn)樗鼘?duì)這個(gè)事務(wù)可見。這個(gè)問題會(huì)存在好幾周，造成表無限制的增長(zhǎng)，后續(xù)的請(qǐng)求全都被拖慢了，從幾毫秒到幾分鐘[腳注4]。雖然這個(gè)問題和 postgres 緊密相關(guān)，但是它很好的說明了程序員一個(gè)簡(jiǎn)單的失誤會(huì)讓應(yīng)用程序陷入一種非?？膳碌臓顟B(tài)。
4. 連接會(huì)停留在已認(rèn)證的狀態(tài)，并且被后續(xù)的連接使用。結(jié)果就是在請(qǐng)求里搞錯(cuò)了用戶。
5. 套接字會(huì)一直打開著。一般情況下 NodeJS 會(huì)在一個(gè)空閑的套接字上應(yīng)用兩分鐘的超時(shí)，但這個(gè)值可以覆蓋，這將會(huì)泄露一個(gè)文件描述符。如果這種情況不斷發(fā)生，程序會(huì)因?yàn)橛霉饬怂械奈募枋龇鴱?qiáng)退。即使不覆蓋這個(gè)超時(shí)時(shí)間，客戶端會(huì)掛兩分鐘直到 “hang-up” 錯(cuò)誤的發(fā)生。這兩分鐘的延遲會(huì)讓問題難于處理和調(diào)試。
6. 很多內(nèi)存引用會(huì)被遺留。這會(huì)導(dǎo)致泄露，進(jìn)而導(dǎo)致內(nèi)存耗盡，GC需要的時(shí)間增加，最后性能急劇下降。這點(diǎn)非常難調(diào)試，而且很需要技巧與導(dǎo)致造成泄露的失誤聯(lián)系起來。
**最好的從失誤恢復(fù)的方法是立刻崩潰**。你應(yīng)該用一個(gè)restarter 來啟動(dòng)你的程序，在奔潰的時(shí)候自動(dòng)重啟。如果restarter 準(zhǔn)備就緒，崩潰是失誤來臨時(shí)最快的恢復(fù)可靠服務(wù)的方法。
奔潰應(yīng)用程序唯一的負(fù)面影響是相連的客戶端臨時(shí)被擾亂，但是記?。?
* 從定義上看，這些錯(cuò)誤屬于Bug。我們并不是在討論正常的系統(tǒng)或是網(wǎng)絡(luò)錯(cuò)誤，而是程序里實(shí)際存在的Bug。它們應(yīng)該在線上很罕見，并且是調(diào)試和修復(fù)的最高優(yōu)先級(jí)。
* 上面討論的種種情形里，請(qǐng)求沒有必要一定得成功完成。請(qǐng)求可能成功完成，可能讓服務(wù)器再次崩潰，可能以某種明顯的方式不正確的完成，或者以一種很難調(diào)試的方式錯(cuò)誤的結(jié)束了。
* 在一個(gè)完備的分布式系統(tǒng)里，客戶端必須能夠通過重連和重試來處理服務(wù)端的錯(cuò)誤。不管 NodeJS 應(yīng)用程序是否被允許崩潰，網(wǎng)絡(luò)和系統(tǒng)的失敗已經(jīng)是一個(gè)事實(shí)了。
* 如果你的線上代碼如此頻繁地崩潰讓連接斷開變成了問題，那么正真的問題是你的服務(wù)器Bug太多了，而不是因?yàn)槟氵x擇出錯(cuò)就崩潰。
如果出現(xiàn)服務(wù)器經(jīng)常崩潰導(dǎo)致客戶端頻繁掉線的問題，你應(yīng)該把經(jīng)歷集中在造成服務(wù)器崩潰的Bug上，把它們變成可捕獲的異常，而不是在代碼明顯有問題的情況下盡可能地避免崩潰。調(diào)試這類問題最好的方法是，把 NodeJS 配置成出現(xiàn)未捕獲異常時(shí)把內(nèi)核文件打印出來。在 GNU/Linux 或者 基于 illumos 的系統(tǒng)上使用這些內(nèi)核文件，你不僅查看應(yīng)用崩潰時(shí)的堆棧記錄，還可以看到傳遞給函數(shù)的參數(shù)和其它的 JavaScript 對(duì)象，甚至是那些在閉包里引用的變量。即使沒有配置 code dumps，你也可以用堆棧信息和日志來開始處理問題。
最后，記住程序員在服務(wù)器端的失誤會(huì)造成客戶端的操作失敗，還有客戶端必須處理好服務(wù)器端的奔潰和網(wǎng)絡(luò)中斷。這不只是理論，而是實(shí)際發(fā)生在線上環(huán)境里。
NIUCLOUD是一款SaaS管理后臺(tái)框架多應(yīng)用插件+云編譯。上千名開發(fā)者、服務(wù)商正在積極擁抱開發(fā)者生態(tài)。歡迎開發(fā)者們免費(fèi)入駐。一起助力發(fā)展！
![]()
廣告