这次给大家带来关于JS抛出错误使用汇总,JS抛出错误的注意事项有哪些,下面就是实战案例,一起来看一下。

在JS中抛出错误是一门艺术。摸清楚代码中哪里合适抛出错误是需要时间的。因此,一旦搞清楚了这一点,调试代码的事件将大大缩短,对代码的满意度将急剧提升。

错误的本质

当某些非期望的事情发生时程序就引发一个错误。也许是给一个函数传递了一个不正确的值,或者是数学运算碰到了一个无效的操作数。编程语言定义了一组基本的规则,当偏离了这些规则时将导致错误,然后开发者能修复代码。如果错误没有被抛出或者报告给你的话,调试是非常困难的。如果所有的失败都是悄无声息的,首要的问题是那必将消耗你大量的时间才能发现它,更不要说单独隔离并修复它了。所以,错误是开发者的朋友,而不是敌人。

错误常常在非期望的地点、不恬当的时机跳出来,这很麻烦。更糟糕的是,默认的错误消息通常太简洁而无法解释到底什么东西出错了。JS错误消息以信息稀少、隐晦含糊而臭名昭著(特别是在老版本的IE中),这只会让问题更加复杂化。想象一下,如果跳出一个错误能这样描述:“由于发生这些情况,该函数调用失败”。那么,调试任务马上就会变得更加简单,这正是抛出自己的错误的好处。

像内置的失败案例一样来考虑错误是非常有帮助的。在代码某个特殊之处计划一个失败总比要在所有的地方都预期失败简单的多。在产品设计上,这是非常普遍的实践经验,而不仅仅是在代码编写方面。汽车尚有碰撞力吸收区域,这些区域框架的设计旨在撞击发生时以可预测的方式崩塌。知道一个碰撞到来时这些框架将如何反应——特别是,哪些部分将失败——制造商将能保证乘客的安全。你的代码也可以用这种方法来创建。

在JS中抛出错误

毫无疑问,在JS中抛出错误要比在任何其他语言中做同样的事情更加有价值,这归咎于Web端调试的复杂性。可以使用throw操作符,将提供的一个对象作为错误抛出。任何类型的对象都可以作为错误抛出,然而,Error对象是最常用的。

throw new Error('Something bad happened.');

内置的Error类型在所有的JS实现中都是有效的,它的构造器只接受一个参数,指代错误消息(message)。当以这种方式抛出错误时,如果没有通过try-catch语句来捕获的话,浏览器通常直接显示该消息(message字符串)。当今大多数浏览器都有一个控制台(console),一旦发生错误都会在这里输出错误信息。换言之,任何你抛出的和没抛出的错误都被以相同的方式来对待。

缺乏经验的开发者有时直接将一个字符串作为错误抛出,如:

// 不好的写法throw 'message';

这样做确实能够抛出一个错误,但不是所有的浏览器做出的响应都会按照你的预期。Firefox、Opera和Chrome都将显示一条“uncaught exception”消息,同时它们包含上述消息字符串。Safari和IE只是简陋地抛出一个“uncaught exception”错误,完全不提供上述消息字符串,这种方式对调试无益。

显然,如果愿意,你可以抛出任何类型的数据。没有任何规则约束不能是特定的数据类型。

throw { name: 'Nicholas' };throw true;throw 12345;throw new Date();

就一件事情需要牢记,如果没有通过try-catch语句捕获,抛出任何值都将引发一个错误。Firefox、Opera和Chrome都会在该抛出的值上调用String()函数,来完成错误消息的显示逻辑,但Safari和IE不是这样的。针对所有的浏览器,唯一不出差错的显示自定义的错误消息的方式就是用一个Error对象。

抛出错误的好处

抛出自己的错误可以使用确切的文本供浏览器显示。除了行和列的号码,还可以包含任何你需要的有助于调试问题的信息。我推荐总是在错误消息中包含函数名称,以及函数失败的原因。考察下面的函数:

function getDivs (element) { return element.getElementsByTagName('div'); }

这个函数旨在获取element元素下所有后代元素中的div元素。传递给函数要操作的DOM元素为null值可能是件很常见的事情,但实际需要的是DOM元素。如果给这个函数传递null会发生什么情况呢?你会看到一个类似“object expected”的含糊的错误消息。然后,你要去看执行栈,再实际定位到源文件中的问题。通过抛出一个错误,调试会更简单:

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

现在给getDivs()函数抛出一个错误,任何时候只要element不满足继续执行的条件,就会抛出一个错误明确地陈述发生的问题。如果在浏览器控制台中输出该错误,你马上能开始调试,并知道最有可能导致该错误的原因是调用函数试图用一个值为null的DOM元素去做进一步的事情。

我倾向于认为抛出错误就像给自己留下告诉自己为什么失败的标签。

何时抛出错误

理解了如何抛出错误只是等式的一个部分,另外一部分就是要理解什么时候抛出错误。由于JS没有类型和参数检查,大量的开发者错误地假设他们自己应该实现每个函数的类型检查。这种做法并不实际,并且会对脚本的整体性能造成影响。考察下面的函数,它试图实现充分的类型检查。

// 不好的做法:检查了太多的错误function addClass (element, className) { if (!element || typeof element.className !== 'string') { throw new Error('addClass(): First argument must be a DOM element.'); } if (typeof className !== 'string') { throw new Error('addClass(): Second argument must be a string.'); } element.className += '' + className; }

这个函数本来只是简单地给一个给定的元素增加一个CSS类名(className),因此,函数的大部分工作变成了错误检查。纵然它能在每个函数中检查每个参数(模仿静态语言),在JS中这么做也会引起过度的杀伤。辨识代码中哪些部分在特定的情况下最有可能导致失败,并只在那些地方抛出错误才是关键所在。

在上例中,最有可能引发错误的是给函数传递一个null引用值。如果第二个参数是null或者一个数字或者一个布尔值是不会抛出错误的,因为JS会将其强制转换为字符串。那意味着导致DOM元素的显示不符合期望,但这并不至于提高到严重错误的程度。所以,我只会检查DOM元素。

// 好的写法function addClass (element, className) { if (!element || typeof element.className !== 'string') { throw new Error('addClass(): First argument must be a DOM element.'); } element.className += '' + className; }