在 Web 前端中,若 JS Runtime 發生錯誤(例如存取 undefined 的屬性),頁面往往會直接變成一片空白,沒有任何提示,讓使用者以為網頁整個掛了。

雖然這對效能沒有幫助,但對使用者體驗來說卻非常關鍵。很多 Web 網站並未針對錯誤做處理。

常見情境

當 Web JS 拋出錯誤或後端 API 欄位漏給資訊,JavaScript 取用 response 不存在的物件 nullundefined下另個不存在的值,就會拋出錯誤,若是沒實作 try-catch 或拋出的錯誤在元件樹層層傳遞都沒被接住,瀏覽器就會一片空白。

這在產品開發上是不太能接受的,通常會有個「something went wrong」的錯誤畫面,提醒使用者網頁壞囉。


例如 2020年 youtube 有爆掉過一次,大家就看猴子一個下午。

面對預料外的錯誤,Client 能做什麼處理?

React 有個處理錯誤畫面的機制叫「錯誤邊界 Error Boundaries」,原理就是在元件樹最上面的根元件,裡面包一個 try catch 機制,當捉到錯誤時就顯示錯誤畫面元件,替換掉網頁的內容。實作上在各頁包入我們自訂的 Error Boundaries 元件即可。

錯誤邊界 – React
A JavaScript library for building user interfaces

實作的迫切程度

取決於 Web 前端產品有多穩定?越穩定公司越不會在意這塊,越新創產品不穩迫切性就越高。實務上通常是 Prod 環境出問題才會回頭來看這塊。

使用 Error Boundaries 的 scope 範圍

理想上各頁都應該要有。

由於 Error Boundaries 錯誤邊界本質上是在 Client 端的 try-catch 的 catch 接住 error 時顯示對應 view ,所以這個 view 要是也拋出錯誤,然後沒有其他 try-catch 機制去接住,那一樣會遇到網頁白畫面狀況。

Error View 不是 500 Page

另外需要強調的是,這種錯誤畫面不是 Web Server 拋出的 500 頁面,而是用來處理 Client Side Runtime Error。

的確在開發上,Error Boundaries 實作的 Error View 可以和 500 Page 使用相同的 UI HTML 與樣式檔案,但是兩者不是同樣的東西。

500 Page 是 Web Server 出錯時返回的頁面、Error View 是 Web Client 出錯時顯示的頁面,錯誤的觸發與返回這個介面的時機點不同。