者｜Lukas Gisder-Dubé

譯者｜謝麗

本文將分三部分分析 JavaScript 中的錯誤，首先我們將了解錯誤的一般情況，之后，我們將關注后端（Node.js + Express.js），最后，我們將重點看下如何處理 React.js 中的錯誤。選擇這些框架，是因為它們是目前最流行的，但是，你應該也能夠將這些新發現應用到其他框架中吧！

繼上一篇文章 (https://link.medium.com/MO32x55aNR) 之后，我想談談錯誤。錯誤很好——我相信你以前聽過這個說法。乍一看，我們害怕錯誤，因為錯誤往往會涉及到在公共場合受到傷害或羞辱。通過犯錯誤，我們實際上學會了如何不去做某事，以及下次如何做得更好。

顯然，這是關于從現實生活的錯誤中學習。編程中的錯誤有點不同。它們為我們提供了很好的特征來改進我們的代碼，并告訴用戶什么地方出了問題（也可能是教他們如何修復它）。

GitHub(https://github.com/gisderdube/graceful-error-handling) 上提供了一個完整的樣例項目。

JavaScript 錯誤和一般處理

throw new Error('something went wrong')?會在 JavaScript 中創建一個錯誤實例，并停止腳本的執行，除非你對錯誤做了一些處理。當你作為 JavaScript 開發者開啟自己的職業生涯時，你自己很可能不會這樣做，但是，你已經從其他庫（或運行時）那里看到了，例如，類似“ReferenceError: fs 未定義”這樣的錯誤。

Error 對象

Error 對象有兩個內置屬性供我們使用。第一個是消息，作為參數傳遞給 Error 構造函數，例如 new Error(“這是錯誤消息”)。你可以通過 message 屬性訪問消息：

const myError=new Error(‘請改進代碼’)
console.log(myError.message) // 請改進代碼

第二個是錯誤堆棧跟蹤，這個屬性非常重要。你可以通過 stack 屬性訪問它。錯誤堆棧將為你提供歷史記錄（調用堆棧），從中可以查看哪個文件導致了錯誤。堆棧的上部也包括消息，然后是實際的堆棧，從距離錯誤發生最近的點開始，一直到最外層“需要為錯誤負責”的文件：

Error: 請改進代碼
 at Object.<anonymous> (/Users/gisderdube/Documents/_projects/hacking.nosync/error-handling/src/general.js:1:79)
 at Module._compile (internal/modules/cjs/loader.js:689:30)
 at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
 at Module.load (internal/modules/cjs/loader.js:599:32)
 at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
 at Function.Module._load (internal/modules/cjs/loader.js:530:3)
 at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
 at startup (internal/bootstrap/node.js:266:19)
 at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)

拋出和處理錯誤

現在，Error 實例本身不會導致任何結果，例如，new Error('...') 不會做任何事情。當錯誤被拋出時，就會變得更有趣。然后，如前所述，腳本將停止執行，除非你在流程中以某種方式對它進行了處理。記住，是手動拋出錯誤，還是由庫拋出錯誤，甚至由運行時本身（Node 或瀏覽器），都沒有關系。讓我們看看如何在不同的場景中處理這些錯誤。

try .... catch

這是最簡單但經常被遺忘的錯誤處理方法——多虧 async / await，它的使用現在又多了起來。它可以用來捕獲任何類型的同步錯誤，例如，如果我們不把 console.log(b) 放在一個 try … catch 塊中，腳本會停止執行。

… finally

有時候，不管是否有錯誤，代碼都需要執行。你可以使用第三個可選塊 finally。通常，這與在 try…catch 語句后面加一行代碼是一樣的，但它有時很有用。

異步性——回調

異步性，這是在使用 JavaScript 時必須考慮的一個主題。當你有一個異步函數，并且該函數內部發生錯誤時，你的腳本將繼續執行，因此，不會立即出現任何錯誤。當使用回調函數處理異步函數時（不推薦），你通常會在回調函數中收到兩個參數，如下所示：

如果有錯誤，err 參數就等同于那個錯誤。如果沒有，參數將是 undefined 或 null。要么在 if(err) 塊中返回某項內容，要么將其他指令封裝在 else 塊中，這一點很重要，否則你可能會得到另一個錯誤，例如，result 可能未定義，而你試圖訪問 result.data，類似這樣的情況。

異步性——Promises

處理異步性的更好方法是使用 Promises。在這一點上，除了代碼可讀性更強之外，我們還改進了錯誤處理。只要有一個 catch 塊，我們就不再需要太關注具體的錯誤捕獲。在鏈接 Promises 時，catch 塊捕獲會自 Promises 執行或上一個 catch 塊以來的所有錯誤。注意，沒有 catch 塊的 Promises 不會終止腳本，但會給你一條可讀性較差的消息，比如：

(node:7741) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: something went wrong
(node:7741) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. */

因此，務必要在 Promises 中加入 catch 塊。

回到 try … catch

隨著 JavaScript 引入 async / await，我們回到了最初的錯誤處理方法，借助 try … catch … finally，錯誤處理變得非常簡單。

因為這和我們處理“普通”同步錯誤的方法是一樣的，所以如果需要的話，更容易使用作用域更大的 catch 語句。

服務器端錯誤的產生和處理

現在，我們已經有了處理錯誤的工具，讓我們看下，我們在實際情況下能用它們做什么。后端錯誤的產生和處理是應用程序至關重要的組成部分。對于錯誤處理，有不同的方法。我將向你展示一個自定義 Error 構造函數和錯誤代碼的方法，我們可以輕松地傳遞到前端或任何 API 消費者。構建后端的細節并不重要，基本思路不變。

我們將使用 Express.js 作為路由框架。讓我們考慮下最有效的錯誤處理結構。我們希望：

1. 一般錯誤處理，如某種回退，基本上只是說：“有錯誤，請再試一次或聯系我們”。這并不是特別聰明，但至少通知用戶，有地方錯了——而不是無限加載或進行類似地處理。
2. 特殊錯誤處理為用戶提供詳細信息，讓用戶了解有什么問題以及如何解決它，例如，有信息丟失，數據庫中的條目已經存在等等。

構建一個自定義 Error 構造函數

我們將使用已有的 Error 構造函數并擴展它。繼承在 JavaScript 中是一件危險的事情，但根據我的經驗，在這種情況下，它非常有用。我們為什么需要它？我們仍然希望堆棧跟蹤給我們一個很好的調試體驗。擴展 JavaScript 原生 Error 構造函數可以讓我們方便地獲得堆棧跟蹤。我們唯一要做的是添加代碼（我們稍后可以通過錯誤代碼訪問）和要傳遞給前端的狀態（http 狀態代碼）。

如何處理路由

在完成 Error 的自定義之后，我們需要設置路由結構。正如我指出的那樣，我們想要一個單點真錯誤處理，就是說，對于每一個路由，我們要有相同的錯誤處理行為。在默認情況下，由于路由都是封裝的，所以 Express 并不真正支持那種方式。

為了解決這個問題，我們可以實現一個路由處理程序，并把實際的路由邏輯定義為普通的函數。這樣，如果路由功能（或任何內部函數）拋出一個錯誤，它將返回到路由處理程序，然后可以傳給前端。當后端發生錯誤時，我們可以用以下格式傳遞一個響應給前端——比如一個 JSON API：

{
 error: 'SOME_ERROR_CODE',
 description: 'Something bad happened. Please try again or contact support.'
}

準備好不知所措。當我說下面的話時，我的學生總是生我的氣：

如果你咋看之下并不是什么都懂，那沒問題。只要使用一段時間，你就會發現為什么要那樣。

順便說一下，這可以稱為自上而下的學習，我非常喜歡。

路由處理程序就是這個樣子：

我希望你能讀下代碼中的注釋，我認為那比我在這里解釋更有意義。現在，讓我們看下實際的路由文件是什么樣子：

在這些例子中，我沒有做任何有實際要求的事情，我只是假設不同的錯誤場景。例如，GET /city 在第 3 行結束，POST /city 在第 8 號結束等等。這也適用于查詢參數，例如，GET /city?startsWith=R。本質上，你會有一個未處理的錯誤，前端會收到：

{
 error: 'GENERIC',
 description: 'Something went wrong. Please try again or contact support.'
}

或者你將手動拋出 CustomError，例如：

throw new CustomError('MY_CODE', 400, 'Error description')

上述代碼會轉換成：

{
 error: 'MY_CODE',
 description: 'Error description'
}

既然我們有了這個漂亮的后端設置，我們就不會再把錯誤日志泄漏到前端，而總是返回有用的信息，說明出現了什么問題。

確保你已經在 GitHub(https://github.com/gisderdube/graceful-error-handling) 上看過完整的庫。你可以把它用在任何項目中，并根據自己的需要來修改它！

向用戶顯示錯誤

下一個也是最后一個步驟是管理前端的錯誤。這里，你要使用第一部分描述的工具處理由前端邏輯產生的錯誤。不過，后端的錯誤也要顯示。首先，讓我們看看如何顯示錯誤。如前所述，我們將使用 React 進行演練。

把錯誤保存在 React 狀態中

和其他數據一樣，錯誤和錯誤消息會變化，因此，你想把它們放在組件狀態中。在默認情況下，你想要在加載時重置錯誤，以便用戶第一次看到頁面時，不會看到錯誤。

接下來我們必須澄清的是不同錯誤類型及與其匹配的可視化表示。就像在后端一樣，有 3 種類型：

1. 全局錯誤，例如，其中一個常見的錯誤是來自后端，或者用戶沒有登錄等。
2. 來自后端的具體錯誤，例如，用戶向后端發送登錄憑證。后端答復密碼不匹配。前端無法進行此項驗證，所以這樣的信息只能來自后端。
3. 由前端導致的具體錯誤，例如，電子郵件輸入驗證失敗。

2 和 3 非常類似，雖然源頭不一樣，但如果你愿意，就可以在同樣的 state 中處理。我們將從代碼中看下如何實現。

我將使用 React 的原生 state 實現，但是，你還可以使用類似 MobX 或 Redux 這樣的狀態管理系統。

全局錯誤

通常，我將把這些錯誤保存在最外層的有狀態組件中，并渲染一個靜態 UI 元素，這可能是屏幕頂部的一個紅色橫幅、模態或其他什么東西，設計實現由你決定。

讓我們看下代碼：

正如你看到的那樣，Application.js 中的狀態存在錯誤。我們也有方法可以重置并改變錯誤的值。我們把值和重置方法傳遞給 GlobalError 組件，在點擊'x'時，該組件會顯示錯誤并重置它。讓我們看看 GlobalError 組件：

你可以看到，在第 5 行，如果沒有錯誤，我們就不做任何渲染。這可以防止我們的頁面上出現一個空的紅框。當然，你可以改變這個組件的外觀和行為。例如，你可以將“x”替換為 Timeout，幾秒鐘后重置錯誤狀態。

現在，你已經準備好在任何地方使用全局錯誤狀態了，只是從 Application.js 把 _setError 向下傳遞，而且，你可以設置全局錯誤，例如，當一個請求從后端返回了字段 error: 'GENERIC'。例如：

如果你比較懶，到這里就可以結束了。即使你有具體的錯誤，你總是可以改變全局錯誤狀態，并把錯誤提示框顯示在頁面頂部。不過，我將向你展示如何處理和顯示具體的錯誤。為什么？首先，這是關于錯誤處理的權威指南，所以我不能停在這里。其次，如果你只是把所有的錯誤都作為全局錯誤來顯示，那么體驗人員會瘋掉。

處理具體的請求錯誤

和全局錯誤類似，我們也有位于其他組件內部的局部錯誤狀態，過程相同：

有件事要記住，清除錯誤通常有一個不同的觸發器。用' x '刪除錯誤是沒有意義的。關于這一點，在發出新請求時清除錯誤會更有意義。你還可以在用戶進行更改時清除錯誤，例如當修改輸入值時。

源于前端的錯誤

如前所述，這些錯誤可以使用與處理后端具體錯誤相同的方式（狀態）進行處理。這次，我們將使用一個有輸入字段的示例，只允許用戶在實際提供以下輸入時刪除一個城市：

使用錯誤代碼實現錯誤國際化

也許你一直想知道為什么我們有這些錯誤代碼，例如 GENERIC ，我們只是顯示從后端傳遞過來的錯誤描述。現在，隨著你的應用越來越大，你就會希望征服新的市場，并在某個時候面臨多種語言支持的問題。如果你到了這個時候，你就可以使用前面提到的錯誤代碼使用用戶的語言來顯示恰當的描述。

我希望你對如何處理錯誤有了一些了解。忘掉 console.error(err)，它現在已經是過去時了。可以使用它進行調試，但它不應該出現在最終的產品構建中。為了防止這種情況，我建議你使用日志庫，我過去一直使用 loglevel，我對它非常滿意。

英文原文

https://levelup.gitconnected.com/the-definite-guide-to-handling-errors-gracefully-in-javascript-58424d9c60e6