以前，我覺得編程語言中最讓人不解的部分就是它能夠創(chuàng)建錯誤。當時我對Java語言中的throw關鍵字的第一反應就是“啊，這也太傻了，為什么我們想要引發(fā)一個錯誤(error)?”我覺得錯誤是我的敵人，應當避免的，所以創(chuàng)建錯誤是毫無用處甚至是危險的。我認為在JavaScript中加入這樣的關鍵字是多此一舉。但隨著我編程經(jīng)驗的豐富，我逐漸變成了throw我的error粉絲。合理的使用它們會讓對代碼的調(diào)試和維護大大簡化。

　　在編程的時候，Error通常出現(xiàn)在不期望的事情發(fā)生時?？赡苁莻魅牒瘮?shù)的參數(shù)值不正確，或者是運算符的操作數(shù)不合法。為此編程語言定義了一個基本的規(guī)則：當上述情況發(fā)生時，就產(chǎn)生一個錯誤來讓編程人員對代碼進行修復。如果這些錯誤不被拋出或反饋給你，那么調(diào)試程序幾乎是不可能的。如果所有的錯誤都“悄悄地”發(fā)生，那么你很難在第一時間發(fā)現(xiàn)問題所在，并將其修復。因此Error是開發(fā)者的朋友，而不是敵人。

　　Error的問題所在是它們會在錯誤的時間和錯誤的地點發(fā)生。更糟的是，默認的錯誤信息通?；逎y懂，很難解釋哪里出了問題。JavaScirpt的錯誤信息更是不包含任何有價值的信息，而且還很隱蔽(尤其是在IE里運行時)。想象一下如果能有這樣的錯誤提示出現(xiàn)“因為某件事情發(fā)生導致某個函數(shù)調(diào)用失敗”，那么立刻我們的調(diào)試任務就變得簡單了，這就是throw自己的error的好處。

　　我們可以把error想象成內(nèi)嵌的異常類。在代碼的某個特定的地點估計異常的發(fā)生肯定要比在所有的地方等待異常的發(fā)生要簡單。這不光在代碼編寫中，在產(chǎn)品設計中也是一個普遍認同的原則。就像在轎車上設計了擠壓區(qū)域和框架，以便在受到撞擊時會以期望的方式發(fā)生變形。因為知道了框架在受到撞擊時會如何變形，哪些零件會失效，這樣制造商就可以造出保證乘客安全的汽車。我們的代碼也可以按照這樣的思想編寫。

　　雖然最近幾年JavaScript有了很多進步，但是相比于其它語言的開發(fā)者，JavaScript開發(fā)者仍然只有少得可憐的調(diào)試工具。因此在JavaScript中throw error就顯得比其它語言更有價值。我們可以用throw關鍵字來拋出一個對象。我們可以拋出任何類型的對象，不過Error對象是最常用的：

　　當我們用這樣的方式拋出錯誤，而這個錯誤又不被try-catch捕獲時，瀏覽器就會用其通常的方式顯示上面的錯誤信息(Something bad happened)。在IE里會在瀏覽器的左下角出現(xiàn)一個小圖標，當雙擊圖標時會彈出一個帶著上面錯誤提示的對話框;安裝有Firebug插件的火狐瀏覽器會在控制臺顯示錯誤信息;Safar和Chrome會在Web Inspector中顯示;Opera會在錯誤控制臺顯示。一句話，它們會像你沒有拋出錯誤時一樣處理。但不同的是它會通過瀏覽器向你提供具體的信息，而不是一個發(fā)生錯誤的行列號。你可以為錯誤信息加入任何需要的信息，來幫你成功解決問題。我建議在錯誤信息中提供發(fā)生錯誤的函數(shù)名稱以及錯誤原因。看下面這個函數(shù)：

　　這個函數(shù)的功能是向一個給定的element加入新的CSS class(這在JavaScript中非常普遍)。但如果element是null的時候會發(fā)生什么?你會得到一個這樣的錯誤提示“object expected”，很隱晦。然后你需要查看執(zhí)行堆棧(如果瀏覽器支持這個功能)來準確定位錯誤的源頭。如果我們拋出一個錯誤調(diào)試就變得簡單了：

　　先不討論如何精確的判斷對象是否是一個DOM element，這個方法現(xiàn)在能夠在非法的element參數(shù)傳入時提供一個更明確的錯誤信息?？吹搅巳绱嗽敱M的錯誤描述你就能立刻找到錯誤的源頭了。我習慣把throw error看作是貼一個任務貼紙，告訴我錯誤的原因。

　　懂得了如何throw error只是事情的一半;懂得何時throw error則是另一半。因為JavaScript并不對參數(shù)進行類型檢查，許多開發(fā)者都錯誤的認為他們應該在所有的函數(shù)中進行該檢查。那樣的話是不實際的，而且會降低腳本的執(zhí)行效率。問題的關鍵在于找到最有可能出錯的代碼部分，并且只在那里throw error。一句話就是只在已經(jīng)發(fā)生error的地方throw error。

　　如果一個函數(shù)只被一個已知的實體調(diào)用，那么錯誤檢查基本上是沒有必要的(例如私有函數(shù)就是這樣);如果你不能事先確定所有函數(shù)被調(diào)用的地點，那么你需要進行錯誤檢查并throw自己的error。throw error最好的地方是功能函數(shù)，那些是腳本環(huán)境基本組成部分的，而且可以在任意地點被調(diào)用的函數(shù)。JavaScript的庫函數(shù)就是這樣的例子。

　　所有JavaScript的庫函數(shù)都應當為已知的錯誤條件從它們的公共接口throw error。對于YUI，jQuery以及Dojo等等，我們無法確定會在何時何處調(diào)用它們的庫函數(shù)。所以當你犯錯時對你進行提示就是這些庫函數(shù)的任務。為什么呢?因為你不可能到庫函數(shù)內(nèi)部去找出錯誤所在。error的調(diào)用堆棧應當終止于庫函數(shù)接口，不要再深入。沒有什么比在12層函數(shù)嵌套中尋找錯誤更遭的事了;庫函數(shù)開發(fā)人員有責任預防這種事情的發(fā)生。

　　這一條同樣適用于私有的JavaScript庫函數(shù)。許多Web應用程序都有它們自己專屬的JavaScript庫，可能是通過這些庫來構建的，也可能是用庫來代替公共的操作。庫函數(shù)的作用是降低開發(fā)難度，這是通過向人們提供其抽象表達而不是復雜的實現(xiàn)細節(jié)來實現(xiàn)的。throw error可以讓這些復雜的實現(xiàn)隱藏在安全的地方不被開發(fā)者發(fā)現(xiàn)。

　　JavaScript同樣提供了try-catch語句，用來在瀏覽器處理之前捕獲被throw的error。開發(fā)者常常會為到底是僅僅throw error還是用try-catch將其捕獲而猶豫不決。我們應當只在程序棧的最底層throw error，就像前面提到的，最典型的就是JavaScript庫函數(shù)。所有應用程序都應當在邏輯上具有處理error的能力，因此應當在底層模塊中捕獲error。

　　在應用程序邏輯中我們總是知道為什么要調(diào)用某個函數(shù)，因此它們非常適合處理error。有一點要引起注意，就是永遠不要在try-catch結構中使用空的catch語句;你應當用某種方法處理錯誤。這鐘處理在開發(fā)中和最終生產(chǎn)時會有些不同，但必須進行處理。當錯誤發(fā)生時，不應當僅僅將其包裹在try-catch里不管——這是掩蓋錯誤而不是解決錯誤。

　　在JavaScript中throw error是一門藝術。在代碼中找到適當?shù)膖hrow error的地點會花費一些時間。不過一旦你找到了這些地點，你的調(diào)試時間就會大大降低，而你對代碼的滿意度會獲得提升。