摘要：我們使用單元測試來驗(yàn)證一下我們使用了配合做單元測試。我們編寫相應(yīng)的單元測試你會(huì)發(fā)現(xiàn)，如果出現(xiàn)異常，只是簡單的返回。但是在上面異常拋出的時(shí)候，解釋器已經(jīng)不在中了，因此無法被捕獲。

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

原文: A Guide to Proper Error Handling in JavaScript Related Topics:

譯者: Fundebug

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權(quán)歸原作者所有，翻譯僅用于學(xué)習(xí)。

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

個(gè)人感覺，事件驅(qū)動(dòng)的編程設(shè)計(jì)使得JavaScript語言非常的豐富靈活。我們設(shè)想瀏覽器就是事件驅(qū)動(dòng)機(jī)器，錯(cuò)誤同樣由它的驅(qū)動(dòng)產(chǎn)生。當(dāng)一個(gè)錯(cuò)誤觸發(fā)，導(dǎo)致某個(gè)事件被拋出。從理論上說，錯(cuò)誤在JavaScript中就是事件。

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

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

我們使用的Demo可以在GitHub下載，程序運(yùn)行起來會(huì)呈現(xiàn)如下頁面：

誤，拋出TypeError。下面是該模塊的定義：

// scripts/error.js

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

在error()中定義了一個(gè)空對象foo，因此調(diào)用foo.bar()會(huì)因?yàn)槲幢欢x而報(bào)錯(cuò)。我們使用單元測試來驗(yàn)證一下：

// tests/scripts/errorTest.js

it("throws a TypeError", function () {
  should.throws(error, TypeError);
});

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

當(dāng)你克隆了代碼庫并安裝了依賴包以后，你可以使用npm t來執(zhí)行測試。當(dāng)然，你也可以執(zhí)行某個(gè)測試文件，比如：./node_modules/mocha/bin/mocha tests/scripts/errorTest.js

相信我，像JavaScript這樣的動(dòng)態(tài)語言來說，不管誰都很容易遇到這樣的錯(cuò)誤。

我已經(jīng)將按鈕對應(yīng)的處理事件函數(shù)抽象得簡單一點(diǎn)，如下所示：

// scripts/badHandler.js

function badHandler(fn) {
  try {
    return fn();
  } catch (e) { }
  return null;
}

badHandler接收一個(gè)fn作為回調(diào)函數(shù)，該回調(diào)函數(shù)在badHandler中被調(diào)用。我們編寫相應(yīng)的單元測試：

// 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);
});

你會(huì)發(fā)現(xiàn)，如果出現(xiàn)異常，badHandler只是簡單的返回null。如果配合完整的代碼，你會(huì)發(fā)現(xiàn)問題所在：

// 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));

如果出錯(cuò)的時(shí)候?qū)⑵鋞ry-catch，然后僅僅返回null，我根本找不到哪里出錯(cuò)了。這種安靜失敗(fail-silent)策略可能導(dǎo)致UI紊亂也可能導(dǎo)致數(shù)據(jù)錯(cuò)亂，并且在Debug的時(shí)候可能花了幾個(gè)小時(shí)卻忽略了try-catch里面的代碼才是致禍根源。如果代碼復(fù)雜到有多層次的調(diào)用，簡直不可能找到哪里出了錯(cuò)。因此，我們不建議使用安靜失敗策略，我們需要更加優(yōu)雅的方式。

// scripts/uglyHandler.js

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

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

// 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);
});

現(xiàn)在，這個(gè)自定義的錯(cuò)誤對象包含了原本錯(cuò)誤的信息，因此變得更加有用。但是因?yàn)樵俣葤伋鰜恚廊皇俏刺幚淼腻e(cuò)誤。

一個(gè)思路是對所有的函數(shù)用try...catch包圍起來：

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

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

// scripts/errorHandlerDom.js

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

你可以將錯(cuò)誤信息發(fā)送到服務(wù)器：

// scripts/errorAjaxHandlerDom.js

window.addEventListener("error", function (e) {
  var stack = e.error.stack;
  var message = e.error.toString();

  if (stack) {
    message += "
" + stack;
  }

  var xhr = new XMLHttpRequest();
  xhr.open("POST", "/log", true);
  // Fire an Ajax request with error details
  xhr.send(message);
});

為了獲取更詳細(xì)的報(bào)錯(cuò)信息，并且省去處理數(shù)據(jù)的麻煩，你也可以使用fundebug的JavaScript監(jiān)控插件三分鐘快速接入bug監(jiān)控服務(wù)。

下面是服務(wù)器接收到的報(bào)錯(cuò)消息：

如果你的腳本是放在另一個(gè)域名下，如果你不開啟CORS，除了Script error.，你將看不到任何有用的報(bào)錯(cuò)信息。如果想知道具體解法，請參考：Script error.全面解析。

由于setTimeout異步執(zhí)行，下面的代碼異常將不會(huì)被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語句只會(huì)捕獲當(dāng)前執(zhí)行環(huán)境下的異常。但是在上面異常拋出的時(shí)候，JavaScript解釋器已經(jīng)不在try...catch中了，因此無法被捕獲。所有的Ajax請求也是這樣。

我們可以稍微改進(jìn)一下，將try...catch寫到異步函數(shù)的回調(diào)中：

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

不過，這樣的套路會(huì)導(dǎo)致項(xiàng)目中充滿了try...catch，代碼非常不簡潔。并且，執(zhí)行JavaScript的V8引擎不鼓勵(lì)在函數(shù)中使用try...catch。好在，我們不需要這么做，全局的錯(cuò)誤處理onerror會(huì)捕獲這些錯(cuò)誤。

我的建議是不要隱藏錯(cuò)誤，勇敢地拋出來。沒有人會(huì)因?yàn)榇a出現(xiàn)bug導(dǎo)致程序崩潰而羞恥，我們可以讓程序中斷，讓用戶重來。錯(cuò)誤是無法避免的，如何去處理它才是最重要的。

版權(quán)聲明:
轉(zhuǎn)載時(shí)請注明作者Fundebug以及本文地址：
https://blog.fundebug.com/201...