讀《編寫可維護的JavaScript》第9、十章總結

第九章 將配置數據從代碼中分離出來

9.2 抽離配置數據

這章比較好理解，也很是常見，做者給的倆個例子就能說明一切：

 // 將配置數據藏在代碼中
    function validate(value) { if (!value) { alert("Invalid value"); location.href = "/errors/invalid.php"; } } function toggleSelected(element) { if (hasClass(element, "selected")) { removeClass(element, "selected"); } else { addClass(element, "selected"); } }

這樣的代碼確定不利於修改和維護，將配置數據(hardcoded)或者咱們稱爲硬編碼（寫死的值）提取出來就豁然開朗了：

 var config = { MSG_INVALID_VALUE: "Invalid value", URL_INVALID: "/errors/invalid.php", CSS_SELECTED: "selected" }; function validate(value) { if (!value) { alert(config.MSG_INVALID_VALUE); location.href = config.URL_INVALID; } } function toggleSelected(element) { if (hasClass(element, config.CSS_SELECTED)) { removeClass(element, config.CSS_SELECTED); } else { addClass(element, config.CSS_SELECTED); } }

 

 9.3 保存配置數據

做者更加推薦將配置數據放於獨立的文件中，這樣更有利於管理。

 

第十章 拋出自定義錯誤

10.2 在JavaScript中拋出錯誤

缺少經驗的開發者有時直接將一個字符串做爲錯誤拋出，如：

 // 很差的寫法 
  throw "message";

 

這樣確實可以跑出一個錯誤，但不是全部的瀏覽器作出的響應都會按照你的預期。FireFox、Opera和Chrome都將顯示一條"uncaught exception"消息，同時它將包含上述消息字符串。Safari和IE只是簡陋的拋出一個」uncaught exception「錯誤，徹底不提供上述消息字符串，這種方式對調試無益。

因此做者推薦對於全部瀏覽器，惟一不出錯的顯示自定義的錯誤消息方式就是用一個Error對象。

throw new Error("Something bad happened")

 

10.3 拋出錯誤的好處

做者推薦老是在錯誤信息中包含函數名稱，以及函數失敗的緣由:

function getDivs(element) { if (element && element.getElementsByTagName) { return element.getElementsByTagName("div"); } else { throw new Error("getDivs(): Argument must be a DOM element"); } }

10.4 什麼時候拋出錯誤

一句話：辨識代碼中哪些部分在特定狀況下最有可能致使失敗，並只在哪些地方拋出錯誤纔是關鍵所在。

做者還寫了一些關於拋出錯誤很好的經驗法則:

• 一旦修復了一個很難調試的錯誤，嘗試增長一倆個自定義錯誤。當再次發生錯誤時，這將有助於更容易地解決問題。
• 若是正在編寫代碼，思考一下：」我但願[某些事情]不會發生，若是發生，個人代碼就會一團糟「。這時，若是」某些事情「發生，就拋出一個錯誤。
• 若是正在編寫的代碼別人(不知道是誰)也會使用,思考一下他們的使用方式，在特定的狀況下拋出錯誤。

PS：這點不少如jQuery的類庫處理的很是好，很值得學習。