如何更好地用Java中的異常拋出

  之前，我以爲編程語言中最讓人不解的部分就是它可以建立錯誤。當時我對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的地點會花費一些時間。不過一旦你找到了這些地點，你的調試時間就會大大下降，而你對代碼的滿意度會得到提高。