JavaScript 中錯誤正確處理方式，你用對了嗎？

原文出處： Camilo Reyes 譯文出處：葡萄城控件

JavaScript的事件驅動範式增添了豐富的語言，也是讓使用JavaScript編程變得更加多樣化。若是將瀏覽器設想爲JavaScript的事件驅動工具，那麼當錯誤發生時，某個事件就會被拋出。理論上能夠認爲這些發生的錯誤只是JavaScript中的簡單事件。

本文將會討論客戶端JavaScript中的錯誤處理。主要介紹JavaScript中的易犯錯誤、錯誤處理、異步代碼編寫等內容。

下面就讓咱們一塊兒看看如何正確處理JavaScript中的錯誤。

Demo演示

本文中使用的demo能夠在GitHub上找到，運行以後會是這樣的頁面：

每一個按鈕都會引起一個「錯誤（Exception）」，同時這個錯誤會模擬出一個被拋出的異常TypeError。下面是模塊的定義：

# scripts/error.js
    function error() {
    var foo = {};
    return foo.bar();
 }複製代碼

首先，這個函數聲明瞭一個空對象foo。須要注意的是，bar( )未在任何地方定義。接下來驗證這個單元測試是否會引起「錯誤」：

# tests/scripts/errorTest.js
it('throws a TypeError', function () {
    should.throws(error, TypeError);
});複製代碼

這個單元測試在Mocha中，同時在 Should.js中有測試聲明。Mocha是測試運行工具，而Should.js是斷言庫。這個單元測試運行在Node上，不須要使用瀏覽器。

error( )定義一個空對象，而後嘗試訪問一個方法。由於bar( )在對象內不存在，因此就會引起異常。這種發生在像JavaScript這樣的動態語言上的錯誤，每一個人可能都會遇到！

錯誤處理（一）

經過如下代碼，對上述錯誤進行處理：

# scripts/badHandler.js
function badHandler(fn) {
    try {
        return fn();
    } catch (e) { }
    return null;
}複製代碼

該處理程序將fn做爲輸入參數，而後fn在處理函數內部會被調用。單元測試會體現出以上錯誤處理程序的做用：

# 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);
});複製代碼

若是出現問題，錯誤處理程序就會返回null。fn( )回調函數能夠指向一個合法的方法或錯誤。

如下的點擊事件會繼續進行事件處理：

# 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));複製代碼

這種處理方式在代碼中隱藏了一個錯誤，而且很難發現。隱藏的錯誤可能會花費好幾個小時的調試時間。尤爲是在具備深度調用堆棧的多層解決方案中，這個錯誤會更難發現。因此這是一種不好的錯誤處理方式。

錯誤處理（二）

下面是另外一個錯誤處理方式。

# scripts/uglyHandler.js
function uglyHandler(fn) {
    try {
    return fn();
  } catch (e) {
    throw new Error('a new error');
}複製代碼

處理異常的方式以下所示：

# tests/scripts/uglyHandlerTest.js
it('returns a new error with errors', function () {
    var fn = function () {
    throw new TypeError('type error');
};
    should.throws(function () {
    uglyHandler(fn);
 }, 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中的異常也是一個事件。發生異常時，解釋器會暫停執行並展開：

# scripts/errorHandlerDom.js
window.addEventListener('error', function (e) {
    var error = e.error;
    console.log(error);
});複製代碼

此事件處理程序會捕獲任何執行上下文中發生的錯誤。各個目標發生的錯誤事件會觸發各類類型的錯誤。這種集中在代碼中的錯誤處理是很是激進的。你可使用菊花鏈處理方式來處理特定的錯誤。若是你遵循SOLID原則，就能夠採用具備單一目的錯誤處理方式。這些處理程序能夠隨時進行註冊，解釋器會循環執行須要執行的處理程序。代碼庫能夠從try…catch塊中釋放出來，這也使得調試變得容易。在JavaScript中，把錯誤處理看成事件處理很重要。

捕獲堆棧

在解決問題時，調用堆棧會很是有用，同時瀏覽器正好能夠提供這些信息。雖然堆棧屬性不是標準的一部分，可是最新的瀏覽器已經能夠查看這些信息了。

下面是在服務器上記錄錯誤的示例：

# 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);
});複製代碼

每一個錯誤處理都具備單個目的，這樣能夠保持代碼的DRY原則（目的單一，不要重複本身原則）。

在瀏覽器中，須要將事件處理添加到DOM。這意味着若是你正在構建第三方庫，那麼你的事件會與客戶端代碼共存。window.addEventListener( )會幫你進行處理，同時也不會抹去現有的事件。

這是服務器上日誌的截圖：

能夠經過命令提示符查看日誌，可是Windows上，日誌是非動態的。

經過日誌能夠清楚的看到，具體什麼狀況觸發了什麼錯誤。在調試時調用堆棧也會很是有用，因此不要低估調用堆棧的做用。

在JavaScript中，錯誤信息僅適用於單個域。由於在使用來自不用域的腳本時，將會看不到任何錯誤詳細信息。

一種解決方案是從新拋出錯誤，同時保留錯誤消息：

try {
    return fn();
} catch (e) {
    throw new Error(e.message);
}複製代碼

一旦從新啓動了錯誤備份，全局錯誤處理程序就會完成其他的工做。確保你的錯誤處理處在相同域中，這樣會保留原始消息，堆棧和自定義錯誤對象。

異步處理

JavaScript在運行異步代碼時，進行下面的異常處理，會產生一個問題：

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

經過單元測試來查看問題：

# tests/scripts/asyncHandlerTest.js
    it('does not catch exceptions with errors', function () {
# // The bomb
    var fn = function () {
    throw new TypeError('type error');
};
# Check that the exception is not caught
    should.doesNotThrow(function () {
    asyncHandler(fn);
    });
});複製代碼

這個異常沒有被捕獲，咱們經過單元測試來驗證。儘管代碼包含了try…catch，可是try…catch語句只能在單個執行上下文中工做。當異常被拋出時，解釋器已經脫離了try…catch，因此異常未被處理。Ajax調用也會發生一樣的狀況。

因此，一種解決方案是在異步回調中捕獲異常：

setTimeout(function () {
    try {
    fn();
} catch (e) {
# Handle this async error
    }
}, 1);複製代碼

這種作法會比較奏效，但仍有很大的改進空間。

首先，這些try…catch block在整個區域糾纏不清。事實上，V8瀏覽器引擎不鼓勵在函數內使用try … catch block。V8是Chrome瀏覽器和Node中使用的JavaScript引擎。一種作法是將try…catch block移動到調用堆棧的頂部，但這卻不適用於異步代碼編程。

因爲全局錯誤處理能夠在任何上下文中執行，因此若是爲錯誤處理添加一個窗口對象，那麼就能保證代碼的DRY和SOLID原則。同時全局錯誤處理也能保證你的異步代碼很乾淨。

如下是該異常處理在服務器上的報告內容。請注意，輸出內容會根據瀏覽器的不一樣而不一樣。

從錯誤處理中能夠看到，錯誤來自於異步代碼的setTimeout( )功能。

結論

在進行錯誤處理時，不要隱藏問題，而應該及時發現問題，並採用各類方法追溯問題的根源以便解決問題。雖然編寫代碼時，時常不免會埋下錯誤，可是咱們也無須爲錯誤的發生過於感到羞愧，及時解決發現問題從而避免更大的問題發生，正是咱們如今須要作的。