编写可维护的JavaScript-第10章-抛出自定义错误

2.在JavaScript中抛出错误

throw new Error("Something bad happend")

不要做下面这个事情:

throw "message"

有些浏览器可能不会提示上述消息

3.抛出错误的好处

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

任何时候只要element不满足继续执行的条件,就会抛出一个错误明确陈述发生的问题。

抛出错误就像给自己留下为什么失败的便签。

4.何时抛出错误

需要判断最有可能引发错误的是什么。

在不能提前确定函数会被调用的地方的时候,最可能需要抛出错误(类似于jQuery)。

几个经验:

  • 修复了一个很难调试的错误,抛出几个错误可以避免再次发生错误
  • 希望[某些事情]不要发生的时候,抛出几个关于[某些事情]的错误
  • 如果自己写的代码别人会使用,思考他们的使用方式,抛出对应的错误

5.try/catch语句

当try块中发生了错误,程序会直接跳到catch中,并传入一个错误对象。

应该try-catch还是throw:

  • 错误应该只在程序深层中抛出
  • try-catch在程序应用层使用
  • catch里面不要什么都不写,要写处理错误的代码

6.错误类型

try {
    // 代码引发错误
} catch (ex) {
    if (ex instanceof TypeError) {
        // 处理 TypeError 错误
    } else if (ex instanceof ReferenceError) {
        // 处理 ReferenceError 错误
    } else {
        // 其他处理
    }
}

也可以自己创造自己的错误类型:

function MyError(message) {
    this.message = message;
}
MyError.prototype = new Error();

然后再稳稳的catch自己的错误:

try {
    // 代码引发错误
} catch (ex) {
    if (ex instanceof MyError) {
        //  处理自己的错误
    } else {
        // 其他处理
    }
}
时间: 2024-10-11 00:54:50

编写可维护的JavaScript-第10章-抛出自定义错误的相关文章

《编写可维护的javascript》读书笔记(中)——编程实践

上篇读书笔记系列之:<编写可维护的javascript>读书笔记(上) 上篇说的是编程风格,记录的都是最重要的点,不讲废话,写的比较简洁,而本篇将加入一些实例,因为那样比较容易说明问题. 二.编程实践 1.UI松耦合 第一.将css从javascript中抽离(要改变dom样式数据,应该去操作dom的class名而非dom的style属性,后续要修改此样式只需到对应的css文件中修改而不用修改js文件): 第二.将javascript从HTML中抽离,比如下面的写法是不好的 <!-- 不

读《编写可维护的javascript》笔记

第一章 基本的格式化 缩进层级:推荐 tab:4; 换行:在运算符后面换行,第二行追加两个缩进: // Good: Break after operator, following line indented two levels callAFunction(document, element, window, "some string value", true, 123, navigator); // Bad: Following line indented only one leve

《编写可维护的javascript》读书笔记(上)

最近在读<编写可维护的javascript>这本书,为了加深记忆,简单做个笔记,同时也让没有读过的同学有一个大概的了解. 一.编程风格 程序是写给人读的,所以一个团队的编程风格要保持一致. 1.缩进:一种是利用制表符缩进,一种是使用空格符缩进,各有利弊,任选一种,保持一致即可.个人比较喜欢制表符缩进. 2.语句结尾需要加上分号,避免没必要的BUG. 3.命名:首先要语义化,使用驼峰式命名法,小驼峰即首字母小写,之后每个单词首字母大写:大驼峰即首字母大写,之后同小驼峰:变量名前缀应该是名词(my

编写可维护的JavaScript之简易模版

/* * 正则替换%s * @para arg1(text) 需要替换的模版 * @para arg2 替换第一处%s * @para arg3 替换第二处%s * 返回替换后的字符串 */ var sprintf = function (text) { var i = 1, args = arguments, len = args.length; return text.replace(/%s/g, function () { return (i < len) ? args[i++] : &quo

编写可维护的JavaScript之事件处理

规则1:隔离应用逻辑 这会让你的代码容易调试 规则2:不要分发事件对象 event对象包含了太多信息 // a good example var handlePopup = { // 事件句柄,处理所有和event对象有关的东西 handleClick: function (e) { // 假设事件支持DOM Level2 e.preventDefault(); e.stopPropagation(); // 传入应用逻辑 this.showPopup(e.clientX, e.clientY)

读《编写可维护的JavaScript》第六章总结

第六章 避免使用全局变量 JavaScript执行环境在很多方面都有其独特之处,全局变量就是其中之一.“全局变量”是一个神秘的对象,它表示了脚本的最外层上下文. 在浏览器中,windows对象往往重载并等同于全局对象,因此任何在全局作用域声明的变量和函数都是windows对象的属性. 6.1 全局变量带来的问题 这个就不用照着书详谈了,当我们进入团队合作编写代码时,若大家自定义的变量都是直接挂载在windows对象上(也就是全局变量),很容易发生命名冲突.像这样: function sayCol

读《编写可维护的JavaScript》第五章总结

第五章 UI层的松耦合 5.1 什么是松耦合 在Web开发中,用户界面是由三个彼此隔离又相互作用的层定义的: HTML是用来定义页面的数据和语义 CSS用来给页面添加样式 JavaScript用来给页面添加行为 我们的目标:确保对一个组件的修改不会经常性地影响其他部分. 结果: 遇到和文本或结构相关的问题,通过查找HTML即可定位 当发生了样式相关的问题,你知道问题出现在CSS中 对于那些行为相关的问题,你直接去JavaScript中找到问题所在 5.2 将JavaScript从CSS中抽离 I

编写可维护的JavaScript-第5章-UI层的松耦合

2.将JavaScript从CSS中抽离 别用CSS表达式(现在也没有了) 3.将CSS从JavaScript中抽离 不要直接使用JS给HTML设置样式,使用className作为CSS和JavaScript的桥梁 4.将JavaScript从HTML中抽离 最好将所有JS全部外置出来 5.将HTML从JavaScript中抽离 从服务器中加载HTML(例如使用jQuery的.load()) 将HTML模版放在HTML文件里面,用注释/Script包起来 使用Handlebar的JavaScri

编写可维护的JavaScript-第12章-浏览器嗅探

1.User-Agent检测 只检测旧版本的浏览器 不要依赖对UA的检测,用户是可以修改的 2.特性检测 就是说,我们可以不检测UA,直接检测特定的方法(例如:getElementById)有没有 探测标准方法 探测不同浏览器的特定方法 方法都没有的时候,提供一个解决方案 3.避免特性推断 不能通过一个特性推断另一个特性也存在