以前，我覺得程式語言中最讓人不解的部分就是它能夠建立錯誤。當時我對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的地點會花費一些時間。不過一旦你找到了這些地點，你的除錯時間就會大大降低，而你對程式碼的滿意度會獲得提升。