以前，我覺得編程語言中最讓人不解的部分就是它能夠創建錯誤。當時我對Java語言中的throw關鍵字的第一反應就是“啊，這也太傻了，為什麼我們想要引發一個錯誤(error)？”我覺得錯誤是我的敵人，應當避免的，所以創建錯誤是毫無用處甚至是危險的。我認為在JavaScript中加入這樣的關鍵字是多此一舉。但隨著我編程經驗的豐富，我逐漸變成了throw我的error粉絲。合理的使用它們會讓對代碼的調試和維護大大簡化。
在編程的時候，Error通常出現在不期望的事情發生時。可能是傳入函數的參數值不正確，或者是運算符的操作數不合法。為此編程語言定義了一個基本的規則：當上述情況發生時，就產生一個錯誤來讓編程人員對代碼進行修復。如果這些錯誤不被拋出或反饋給你，那麼調試程序幾乎是不可能的。如果所有的錯誤都“悄悄地”發生，那麼你很難在第一時間發現問題所在，並將其修復。因此Error是開發者的朋友，而不是敵人。
Error的問題所在是它們會在錯誤的時間和錯誤的地點發生。更糟的是，默認的錯誤信息通常晦澀難懂，很難解釋哪裡出了問題。JavaScirpt的錯誤信息更是不包含任何有價值的信息，而且還很隱蔽(尤其是在IE裡運行時)。想象一下如果能有這樣的錯誤提示出現“因為某件事情發生導致某個函數調用失敗”，那麼立刻我們的調試任務就變得簡單了，這就是throw自己的error的好處。
我們可以把error想象成內嵌的異常類。在代碼的某個特定的地點估計異常的發生肯定要比在所有的地方等待異常的發生要簡單。這不光在代碼編寫中，在產品設計中也是一個普遍認同的原則。就像在轎車上設計了擠壓區域和框架，以便在受到撞擊時會以期望的方式發生變形。因為知道了框架在受到撞擊時會如何變形，哪些零件會失效，這樣制造商就可以造出保證乘客安全的汽車。我們的代碼也可以按照這樣的思想編寫。
雖然最近幾年JavaScript有了很多進步，但是相比於其它語言的開發者，JavaScript開發者仍然只有少得可憐的調試工具。因此在JavaScript中throw error就顯得比其它語言更有價值。我們可以用throw關鍵字來拋出一個對象。我們可以拋出任何類型的對象，不過Error對象是最常用的：
throw new Error("Something bad happened.")
當我們用這樣的方式拋出錯誤，而這個錯誤又不被try-catch捕獲時，浏覽器就會用其通常的方式顯示上面的錯誤信息(Something bad happened)。在IE裡會在浏覽器的左下角出現一個小圖標，當雙擊圖標時會彈出一個帶著上面錯誤提示的對話框；安裝有Firebug插件的火狐浏覽器會在控制台顯示錯誤信息；Safar和Chrome會在Web Inspector中顯示；Opera會在錯誤控制台顯示。一句話，它們會像你沒有拋出錯誤時一樣處理。但不同的是它會通過浏覽器向你提供具體的信息，而不是一個發生錯誤的行列號。你可以為錯誤信息加入任何需要的信息，來幫你成功解決問題。我建議在錯誤信息中提供發生錯誤的函數名稱以及錯誤原因。看下面這個函數：
function addClass(element, className){
element.className += " " + className;
}
這個函數的功能是向一個給定的element加入新的CSS class(這在JavaScript中非常普遍)。但如果element是null的時候會發生什麼？你會得到一個這樣的錯誤提示“object expected”，很隱晦。然後你需要查看執行堆棧(如果浏覽器支持這個功能)來准確定位錯誤的源頭。如果我們拋出一個錯誤調試就變得簡單了：
function addClass(element, className){
if (element != null && typeof element.className == "string"){
element.className += " " + className;
} else {
throw new Error("addClass(): First arg must be a DOM element.");
}
}
先不討論如何精確的判斷對象是否是一個DOM element，這個方法現在能夠在非法的element參數傳入時提供一個更明確的錯誤信息。看到了如此詳盡的錯誤描述你就能立刻找到錯誤的源頭了。我習慣把throw error看作是貼一個任務貼紙，告訴我錯誤的原因。
懂得了如何throw error只是事情的一半；懂得何時throw error則是另一半。因為JavaScript並不對參數進行類型檢查，許多開發者都錯誤的認為他們應該在所有的函數中進行該檢查。那樣的話是不實際的，而且會降低腳本的執行效率。問題的關鍵在於找到最有可能出錯的代碼部分，並且只在那裡throw error。一句話就是只在已經發生error的地方throw error。
如果一個函數只被一個已知的實體調用，那麼錯誤檢查基本上是沒有必要的(例如私有函數就是這樣)；如果你不能事先確定所有函數被調用的地點，那麼你需要進行錯誤檢查並throw自己的error。throw error最好的地方是功能函數，那些是腳本環境基本組成部分的，而且可以在任意地點被調用的函數。JavaScript的庫函數就是這樣的例子。
所有JavaScript的庫函數都應當為已知的錯誤條件從它們的公共接口throw error。對於YUI，jQuery以及Dojo等等，我們無法確定會在何時何處調用它們的庫函數。所以當你犯錯時對你進行提示就是這些庫函數的任務。為什麼呢？因為你不可能到庫函數內部去找出錯誤所在。error的調用堆棧應當終止於庫函數接口，不要再深入。沒有什麼比在12層函數嵌套中尋找錯誤更遭的事了；庫函數開發人員有責任預防這種事情的發生。
這一條同樣適用於私有的JavaScript庫函數。許多Web應用程序都有它們自己專屬的JavaScript庫，可能是通過這些庫來構建的，也可能是用庫來代替公共的操作。庫函數的作用是降低開發難度，這是通過向人們提供其抽象表達而不是復雜的實現細節來實現的。throw error可以讓這些復雜的實現隱藏在安全的地方不被開發者發現。
JavaScript同樣提供了try-catch語句，用來在浏覽器處理之前捕獲被throw的error。開發者常常會為到底是僅僅throw error還是用try-catch將其捕獲而猶豫不決。我們應當只在程序棧的最底層throw error，就像前面提到的，最典型的就是JavaScript庫函數。所有應用程序都應當在邏輯上具有處理error的能力，因此應當在底層模塊中捕獲error。
在應用程序邏輯中我們總是知道為什麼要調用某個函數，因此它們非常適合處理error。有一點要引起注意，就是永遠不要在try-catch結構中使用空的catch語句；你應當用某種方法處理錯誤。這鐘處理在開發中和最終生產時會有些不同，但必須進行處理。當錯誤發生時，不應當僅僅將其包裹在try-catch裡不管——這是掩蓋錯誤而不是解決錯誤。
在JavaScript中throw error是一門藝術。在代碼中找到適當的throw error的地點會花費一些時間。不過一旦你找到了這些地點，你的調試時間就會大大降低，而你對代碼的滿意度會獲得提升。
