應用程序邏輯總是知道調用某個特定函數的原因,因此也是最合適處理錯誤的。千萬不要將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