應用程序邏輯總是知道調用某個特定函數的原因，因此也是最合適處理錯誤的。千萬不要將try-catch中的catch塊留空，你應該總是寫點什么來處理錯誤。例如，不要像下面這樣做：

try {
 somethingThatMightCauseAnError();
} catch (ex) { // do nothing}

如果知道可能要發生錯誤，那肯定知道如何從錯誤中恢復。確切地說，如何從錯誤中恢復在開發模式中與實際放到生產環境中是不一樣的，這沒關系。最重要的是，你實實在在地在處理錯誤，而不是忽略它。

ECMA-262規范指出了7種錯誤類型。當不同錯誤條件發生時，這些類型在JS引擎中都有用到，當然我們也可以手動創建它們。

Error: 所有錯誤的基本類型。實際上引擎從來不會拋出該類型的錯誤。

EvalError: 通過eval()函數執行代碼發生錯誤時拋出。

RangeError: 一個數字超出它的邊界時拋出——例如，試圖創建一個長度為-20的數組（new Array(-20);）。該錯誤在正常的代碼執行中非常罕見。

ReferenceError: 期望的對象不存在時拋出——例如，試圖在一個null對象引用上調用一個函數。

SyntaxError: 代碼有語法錯誤時拋出。

TypeError: 變量不是期望的類型時拋出。例如，new 10或'prop' in true。

URIError: 給encodeURI()、encodeURIComponent()、decodeURI()或者decodeURIComponent()等函數傳遞格式非法的URI字符串時拋出。

理解錯誤的不同類型可以幫助我們更容易地處理它。所有的錯誤類型都繼承自Error，所以用instanceof Error檢查其類型得不到任何有用的信息。通過檢查特定的錯誤類型可以更可靠地處理錯誤。

try { // 有些代碼引發了錯誤} catch (ex) { if (ex instanceof TypeError) { // 處理TypeError錯誤
 } else if (ex instanceof ReferenceError) { // 處理ReferenceError錯誤
 } else { // 其他處理
 }
}

如果拋出自己的錯誤，并且是數據類型而不是一個錯誤，你可以非常輕松地區分自己的錯誤和瀏覽器的錯誤類型的不同。但是，拋出實際類型的錯誤與拋出其他類型的對象相比，有幾大優點。

首先，如上討論，在瀏覽器正常錯誤處理機制中會顯示錯誤消息。其次，瀏覽器給拋出的Error對象附加了一些額外的信息。這些信息不同瀏覽器各不相同，但它們為錯誤提供了如行、列號等上下文信息，在有些瀏覽器中也提供了堆棧和源代碼信息。當然，如果用了Error的構造器，你就喪失了區分自己拋出的錯誤和瀏覽器錯誤的能力。

解決方案就是創建自己的錯誤類型，讓它繼承自Error。這種做法允許你提供額外的信息，同時可區別于瀏覽器拋出的錯誤。可以用如下的模式來創建自定義的錯誤類型。

function MyError (message) { this.message = message;
}
MyError.prototype = new Error();

這段代碼有兩個重要的部分：message屬性，瀏覽器必須要知道的錯誤消息字符串；設置prototype為Error的一個實例，這樣對JS引擎而言就標識它是一個錯誤對象了。接下來就可以拋出一個MyError的實例對象，使得瀏覽器能像處理原生錯誤一樣做出響應。

throw new MyError('Hello World!');

提醒一下，該方法在IE8和更早的瀏覽器中不顯示錯誤消息。相反，會看見那個通用的“Exception thrown but not caught”消息。這個方法最大的好處是，自定義錯誤類型可以檢測自己的錯誤。

try { // 有些代碼引發了錯誤} catch (ex) { if (ex instanceof MyError) { // 處理自己的錯誤
 } else { // 其他處理
 }
}

如果總是捕獲你自己拋出的所有錯誤，那么IE的那點兒小愚蠢也不足為道了。在一個正確的錯誤處理系統中獲得的好處是巨大的。該方法可以給出更多、更靈活的信息，告知開發者如何正確地處理錯誤。

相信看了本文案例你已經掌握了方法，更多精彩請關注Gxl網其它相關文章！

推薦閱讀：

web開發中如何避免空比較

為什么web開發中需要避免使用全局變量

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com