處理JavaScript異常的正確姿勢

  • 2019 年 12 月 31 日
  • 筆記

譯者按： 錯誤是無法避免的，妥善處理它才是最重要的！

本文採用意譯，版權歸原作者所有

如果你相信墨菲定律的話，任何事情如果會出問題，那麼就一定會出問題。對於程式碼，即使我們有 100%的自信沒有問題，依然有可能出問題。在這篇文章，我們來研究如何處理 JavaScript 的錯誤。我會先介紹壞的處理方式、好的處理方式，最終介紹非同步程式碼和 Ajax。

個人感覺，事件驅動的編程設計使得 JavaScript 語言非常的豐富靈活。我們設想瀏覽器就是事件驅動機器，錯誤同樣由它的驅動產生。當一個錯誤觸發，導致某個事件被拋出。從理論上說，錯誤在 JavaScript 中就是事件。

如果你對此感到陌生，那麼暫且不管它。在這篇文章中，我主要關注瀏覽器端的 JavaScript。

這篇文章基於JavaScript 中的錯誤處理部分的概念。如果你還不熟悉，我建議你先閱讀一下。

Demo 演示

我們使用的 Demo 可以在GitHub下載，程式運行起來會呈現如下頁面：

所有的按鈕都會觸發錯誤，拋出TypeError。下面是該模組的定義：

// scripts/error.js    function error() {      var foo = {};      return foo.bar();  }

在error()中定義了一個空對象foo，因此調用foo.bar()會因為未被定義而報錯。我們使用單元測試來驗證一下：

// tests/scripts/errorTest.js    it("throws a TypeError", function() {      should.throws(error, TypeError);  });

我們使用了Mocha配合Should.js做單元測試。

當你克隆了程式碼庫並安裝了依賴包以後，你可以使用 npm t 來執行測試。當然，你也可以執行某個測試文件，比如：./node_modules/mocha/bin/mocha tests/scripts/errorTest.js

相信我，像 JavaScript 這樣的動態語言來說，不管誰都很容易遇到這樣的錯誤。

壞的處理方式

我已經將按鈕對應的處理事件函數抽象得簡單一點，如下所示：

// scripts/badHandler.js    function badHandler(fn) {      try {          return fn();      } catch (e) {}      return null;  }

badHandler接收一個fn作為回調函數，該回調函數在badHandler中被調用。我們編寫相應的單元測試：

// tests/scripts/badHandlerTest.js    it("returns a value without errors", function() {      var fn = function() {          return 1;      };        var result = badHandler(fn);        result.should.equal(1);  });    it("returns a null with errors", function() {      var fn = function() {          throw new Error("random error");      };        var result = badHandler(fn);        should(result).equal(null);  });

你會發現，如果出現異常，badHandler只是簡單的返回null。如果配合完整的程式碼，你會發現問題所在：

// scripts/badHandlerDom.js    (function(handler, bomb) {      var badButton = document.getElementById("bad");        if (badButton) {          badButton.addEventListener("click", function() {              handler(bomb);              console.log("Imagine, getting promoted for hiding mistakes");          });      }  })(badHandler, error);

如果出錯的時候將其 try-catch，然後僅僅返回null，我根本找不到哪裡出錯了。這種安靜失敗(fail-silent)策略可能導致 UI 紊亂也可能導致數據錯亂，並且在 Debug 的時候可能花了幾個小時卻忽略了 try-catch 裡面的程式碼才是致禍根源。如果程式碼複雜到有多層次的調用，簡直不可能找到哪裡出了錯。因此，我們不建議使用安靜失敗策略，我們需要更加優雅的方式。

不壞但很爛的方式

// scripts/uglyHandler.js    function uglyHandler(fn) {      try {          return fn();      } catch (e) {          throw new Error("a new error");      }  }

它處理錯誤的方式是抓到錯誤e，然後拋出一個新的錯誤。這樣做的確優於之前安靜失敗的策略。如果出了錯，我可以一層層找回去，直到找到原本拋出的錯誤e。簡單的拋出一個Error('a new error')資訊量比較有限，不精確，我們來自定義錯誤對象，傳出更多資訊：

// scripts/specifiedError.js    // Create a custom error  var SpecifiedError = function SpecifiedError(message) {      this.name = "SpecifiedError";      this.message = message || "";      this.stack = new Error().stack;  };    SpecifiedError.prototype = new Error();  SpecifiedError.prototype.constructor = SpecifiedError;    // scripts/uglyHandlerImproved.js    function uglyHandlerImproved(fn) {      try {          return fn();      } catch (e) {          throw new SpecifiedError(e.message);      }  }    // tests/scripts/uglyHandlerImprovedTest.js    it("returns a specified error with errors", function() {      var fn = function() {          throw new TypeError("type error");      };        should.throws(function() {          uglyHandlerImproved(fn);      }, SpecifiedError);  });

現在，這個自定義的錯誤對象包含了原本錯誤的資訊，因此變得更加有用。但是因為再度拋出來，依然是未處理的錯誤。

截獲異常

一個思路是對所有的函數用try...catch包圍起來：

function main(bomb) {      try {          bomb();      } catch (e) {          // Handle all the error things      }  }

但是，這樣的程式碼將會變得非常臃腫、不可讀，而且效率低下。是否還記得？在本文開始我們有提到在 JavaScript 中異常不過也是一個事件而已，幸運的是，有一個全局的異常事件處理方法(onerror)。

// scripts/errorHandlerDom.js    window.addEventListener("error", function(e) {      var error = e.error;      console.log(error);  });

獲取堆棧資訊

你可以將錯誤資訊發送到伺服器：

// scripts/errorAjaxHandlerDom.js    window.addEventListener("error", function(e) {      var stack = e.error.stack;      var message = e.error.toString();        if (stack) {          message += "n" + stack;      }        var xhr = new XMLHttpRequest();      xhr.open("POST", "/log", true);      // Fire an Ajax request with error details      xhr.send(message);  });

為了獲取更詳細的報錯資訊，並且省去處理數據的麻煩，你也可以使用 fundebug 的JavaScript 監控插件三分鐘快速接入 bug 監控服務。

下面是伺服器接收到的報錯消息：

如果你的腳本是放在另一個域名下，如果你不開啟CORS，除了Script error.，你將看不到任何有用的報錯資訊。如果想知道具體解法，請參考：Script error.全面解析。

非同步錯誤處理

由於setTimeout非同步執行，下面的程式碼異常將不會被try...catch捕獲：

// scripts/asyncHandler.js    function asyncHandler(fn) {      try {          // This rips the potential bomb from the current context          setTimeout(function() {              fn();          }, 1);      } catch (e) {}  }

try...catch語句只會捕獲當前執行環境下的異常。但是在上面異常拋出的時候，JavaScript 解釋器已經不在try...catch中了，因此無法被捕獲。所有的 Ajax 請求也是這樣。

我們可以稍微改進一下，將try...catch寫到非同步函數的回調中：

setTimeout(function() {      try {          fn();      } catch (e) {          // Handle this async error      }  }, 1);

不過，這樣的套路會導致項目中充滿了try...catch，程式碼非常不簡潔。並且，執行 JavaScript 的 V8 引擎不鼓勵在函數中使用try...catch。好在，我們不需要這麼做，全局的錯誤處理onerror會捕獲這些錯誤。

結論

我的建議是不要隱藏錯誤，勇敢地拋出來。沒有人會因為程式碼出現 bug 導致程式崩潰而羞恥，我們可以讓程式中斷，讓用戶重來。錯誤是無法避免的，如何去處理它才是最重要的。

版權聲明

轉載時請註明作者 Fundebug以及本文地址： https://blog.fundebug.com/2017/11/27/proper-error-handling-javascript/

VirMach 便宜 VPS

QNews

QNews