读《编写可维护的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的类库处理的很是好，很值得学习。