读《编写可维护的JavaScript》第九、十章总结

第九章 将配置数据从代码中分离出来

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的类库处理的非常好，很值得学习。