駁《慎用trycatch》

NO IMAGE

今天在掘金看到了一篇文章,慎用 try catch,發佈者的暱稱是“前端妹子”。根據我的經驗,這種暱稱一般都不是妹子,大概率是營銷號(PS:如果能換個美女頭像就更走心了)。(這個還真是個妹子,之前言論欠妥,在此先向妹子道歉。)

駁《慎用trycatch》

看完之後我評論道:“很難相信這是 2018 年寫的文章”。

一般對於這種孰優孰劣的文章我的態度是直接無視,但是這篇的文章的誤導性太大了,有必要反駁一下。

觀點一:try catch 耗性能(誤)

V8 的 TurboFan 引擎從 2013 年就開始開發,並隨 Chrome 59 發佈,try/catch 已經可以進行優化了,完全不用再擔心性能問題。

觀點二:try catch 捕獲不到異步錯誤

第二個是正確的,try/catch 無法捕獲異步異常。

但是,不用 try/catch 一樣捕獲不到。js 對於這種情況確實無能為力。考慮如下代碼

setTimeout(()=> {
throw new Error('can you catch me!!!');
})

無論使用什麼方式,都無法捕獲異常。歸根結底這是代碼編寫的問題,而非 try/catch 的問題。

觀點三:try catch可能會導致報錯點更模糊(誤)

try/catch 並不會讓報錯信息變模糊。

try catch 語句中報錯直接到 catch 中處理,而瀏覽器控制檯看不到報錯信息。

這個鍋 try/catch 可不背,這是開發者的鍋。

如果有了 --async-stack-traces 參數,異步錯誤也變得更加清晰。

而另一個觀點則暴露了作者的無知:

很多人並沒有在catch中拋出報錯信息,或改寫成自己隨意寫的報錯文言,其實不如直接看瀏覽器原生的報錯修改 bug 更方便

這句話完全錯誤,不要誤導讀者了。

首先,js 是單線程,當腳本拋出了未捕獲的異常會使得這個腳本掛起,後面的代碼無法執行。

再者,即使我們使用了 try/catch,依然可以在瀏覽器中看到完整的報錯棧信息。

如果作者不會使用 Chrome Devtools,我寫一個簡短的教程。

駁《慎用trycatch》

在我標註了 ① 的地方,這個功能是“Pause on exceptions”,當拋出未捕獲的異常時,調試器會在此中斷。如果不選中,則只會在控制檯輸出報錯信息,而不會開啟調試器並暫停到拋出異常的位置。

在圖 ② 的地方,如果選中了,即使我們使用 try/catch 捕獲了這個異常,調試器依然會中斷在異常的位置。所以放心的使用 try/catch 吧,你的異常信息不會丟失的,不用擔心“瀏覽器控制檯看不到報錯信息”。

在圖 ③ 的地方,就是前面提到的 V8 的 --async-stack-traces 特性,這個在 Chrome 中是默認開啟的。我們可以看到異步的堆棧信息,更加方便的調試程序。

對於某些喜歡依賴 console.log 進行調試的開發者們,Chrome Devtools 也很貼心的開發了 logpoints 功能:

駁《慎用trycatch》

對於找不到這個功能的,首先確認瀏覽器版本是 73。目前穩定版是 71,可以下載 Chrome Canary

地址欄輸入:chrome://flags/#enable-devtools-experiments 開啟試驗功能。然後安裝上面的動圖設置。

思考

這篇文章帶給我們的思考。

  1. 對於讀者:不要妄圖通過二手資料來學習,對於某個有爭議的觀點,我們應該去尋找最初的參考來源。
  2. 對於社區:掘金是否應該增加舉報或者某些機制,來限制這種“只有流量”,但是“毫無營養”的文章出現在首頁。
  3. 對於作者:一般讀者期望的文章是“解決方案”,而不是“問題”:我們不希望看到“XXX不好”、“XXX有問題”,我們更歡迎“XXX不好,我們應該YYY”,“XXX有問題,我們應該YYY解決”。

相關文章

JSI小試牛刀——Native同步調用JS代碼

iOSDeepLink調研與實踐

canvas+js從0開始擼一個俄羅斯方塊

ReactNative實現AppStoreToday頁效果