第九章 将配置数据从代码中分离出来
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的类库处理的非常好，很值得学习。