駁《慎用 try catch》

今天在掘金看到了一篇文章，慎用 try catch，發佈者的暱稱是「前端妹子」。根據個人經驗，這種暱稱通常都不是妹子，大機率是營銷號（PS：若是能換個美女頭像就更走心了）。（這個還真是個妹子，以前言論欠妥，在此先向妹子道歉。）

看完以後我評論道：「很難相信這是 2018 年寫的文章」。

通常對於這種孰優孰劣的文章個人態度是直接無視，可是這篇的文章的誤導性太大了，有必要反駁一下。

觀點一：try catch 耗性能（誤）

V8 的 TurboFan 引擎從 2013 年就開始開發，並隨 Chrome 59 發佈，try/catch 已經能夠進行優化了，徹底不用再擔憂性能問題。

• V8: Behind the Scenes (November Edition feat. Ignition+TurboFan and ES2015)

觀點二：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 參數，異步錯誤也變得更加清晰。

• 更快的異步函數和 Promise

而另外一個觀點則暴露了做者的無知：

不少人並無在catch中拋出報錯信息，或改寫成本身隨意寫的報錯文言，其實不如直接看瀏覽器原生的報錯修改 bug 更方便

這句話徹底錯誤，不要誤導讀者了。

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

再者，即便咱們使用了 try/catch，依然能夠在瀏覽器中看到完整的報錯棧信息。

若是做者不會使用 Chrome Devtools，我寫一個簡短的教程。

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

在圖 ② 的地方，若是選中了，即便咱們使用 try/catch 捕獲了這個異常，調試器依然會中斷在異常的位置。因此放心的使用 try/catch 吧，你的異常信息不會丟失的，不用擔憂「瀏覽器控制檯看不到報錯信息」。

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

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

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

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

思考

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

1. 對於讀者：不要妄圖經過二手資料來學習，對於某個有爭議的觀點，咱們應該去尋找最初的參考來源。
2. 對於社區：掘金是否應該增長舉報或者某些機制，來限制這種「只有流量」，可是「毫無養分」的文章出如今首頁。
3. 對於做者：通常讀者指望的文章是「解決方案」，而不是「問題」：咱們不但願看到「XXX很差」、「XXX有問題」，咱們更歡迎「XXX很差，咱們應該YYY」，「XXX有問題，咱們應該YYY解決」。