顯式和隱藏異常及錯誤參數

設計應用程序時，我們需要考慮到如何去處理髮生的錯誤，例如錯誤日誌記錄、錯誤干預。可以簡單理解為，在哪裡可能出現錯誤，那麼我們需要捕獲並且處理。在本書中，我們會介紹在Node應用中可能發生的各種形式的錯誤。

那一些明確由throw關鍵詞觸發的異常拋出我們稱為顯式異常。它們即表示了有錯誤發生了：

function formatName (name) {

if (!name) throw new Error("name is required");

...

}

try {

formatName();

} catch (err) {

console.log(err.message, err.stack);

}

如果你嘗試拋出自定義的異常，那麼有一些規則需要銘記於心：throw只能用於同步方法中。或者當非同步方法中非同步執行觸發前throw會生效。（例如誤用API）。通常拋出的異常對象都要繼承於Error。使用簡單的字元串（如throw"Oh no!"）無法獲取對應的調試堆棧，即無法獲取哪裡發生錯誤的相關信息。不要在內置的Node方法中的回調函數中拋出異常；這樣子捕獲到的堆棧沒有什麼有效的信息。我們可以直接處理異常或者把異常傳遞給另外的適合處理錯誤的函數。如果結構支持，你可以在非同步塊中也使用throw了。例如部分非穩定的特性，如domains、promise、generators。

隱藏的異常是指在JavaScript運行時不是由throw關鍵字觸發的異常。不幸的是，這些異常很容易就溜進我們的代碼中。其中一個很常見的異常是ReferenceError，當變數或者屬性的引用未找到時會發生。這裡，我們來看一個因為data的錯誤拼寫導致的異常：

function (err, data) {

}

另外一個很常見的異常是SyntaxError，最出名的就是使用JSON.parse來解析無效JSON數據：

一種很棒的方式來發現隱藏的異常是使用類似JSHint或者JSLint的工具。把它們加入到你構建的過程中來保障代碼得到有效的檢查。這一章後續我們會了解更多關於這方面的內容。

在Node中，錯誤事件可以在任意繼承EventEmitter的對象中觸發。如果沒有相應的處理，Node則會拋出錯誤異常。這些事件如果未綁定處理函數，是調試中最有難度的，因為可能在非同步處理過程中會發生多次錯誤，類似有極少調用堆棧的stream數據：

幸運的是，我們知道這個錯誤來自哪裡：就在我們剛寫的那一點點代碼里。但是在大型的應用中，有可能是因為DNS層出現錯誤，而我們無從得知哪個模塊用了DNS而導致的問題。所以，儘可能地綁定錯誤處理事件：

ee.on("error", function (err) {

console.error(err.message, err.stack);

});

當編寫自定義的EventEmitters對象時，在自己的執行代碼以及定義的API中發生錯誤時，需要提供依賴的相關上下文，來拋給上層以便調試。同樣地，使用Error對象而非字元串，以便找到對應的錯誤堆棧信息。

在非同步操作中發生的錯誤通常會作為回調函數的第一個參數傳遞過去。這和我們前邊提到的錯誤不一樣，這些通常不會直接引起異常。但是它們可能是部分隱藏的異常的源頭。

var data = buf.toString();

...

});

如上，我們忽略readFile返回的錯誤，假定獲取的文件數據已經返回了對應的buffer。不幸的是，當某一天無法讀取相應的文件時，就會因為buf無法獲取而拋出一個ReferenceError異常。這是處理異常錯誤很棒的方法，這意味著很多時間，簡單地把錯誤傳入對應的錯誤處理函數即可優雅地處理好。

處理好我們提及的這四種類型的錯誤，可以讓我們在遇到需要調試的問題時來獲取更多有用的幫助信息。儘管有很多優秀的實踐經驗和工具，但是我們還是會發現一些導致程序崩潰的異常。我們需要了解一下如何設計應用來確保可以快速地定位和修複發生的異常。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！