JavaScript 中遇到的錯誤問題，該怎麼處理？

JavaScript的事件驅動正規化增添了豐富的語言，也是讓使用JavaScript程式設計變得更加多樣化。如果將瀏覽器設想為JavaScript的事件驅動工具，那麼當錯誤發生時，某個事件就會被丟擲。理論上可以認為這些發生的錯誤只是JavaScript中的簡單事件。

下面就讓我們一起看看如何正確處理JavaScript中的錯誤。

Demo演示

每個按鈕都會引發一個“錯誤（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( )功能。

結論

在進行錯誤處理時，不要隱藏問題，而應該及時發現問題，並採用各種方法追溯問題的根源以便解決問題。雖然編寫程式碼時，時常難免會埋下錯誤，但是我們也無須為錯誤的發生過於感到羞愧，及時解決發現問題從而避免更大的問題發生，正是我們現在需要做的。

本文摘自，如有侵權請及時告知，謝謝。