应用程序逻辑总是知道调用某个特定函数的原因，因此也是最合适处理错误的。千万不要将try-catch中的catch块留空，你应该总是写点什么来处理错误。例如，不要像下面这样做：

try {
 somethingThatMightCauseAnError();
} catch (ex) { // do nothing}

如果知道可能要发生错误，那肯定知道如何从错误中恢复。确切地说，如何从错误中恢复在开发模式中与实际放到生产环境中是不一样的，这没关系。最重要的是，你实实在在地在处理错误，而不是忽略它。

ECMA-262规范指出了7种错误类型。当不同错误条件发生时，这些类型在JS引擎中都有用到，当然我们也可以手动创建它们。

Error: 所有错误的基本类型。实际上引擎从来不会抛出该类型的错误。

EvalError: 通过eval()函数执行代码发生错误时抛出。

RangeError: 一个数字超出它的边界时抛出——例如，试图创建一个长度为-20的数组（new Array(-20);）。该错误在正常的代码执行中非常罕见。

ReferenceError: 期望的对象不存在时抛出——例如，试图在一个null对象引用上调用一个函数。

SyntaxError: 代码有语法错误时抛出。

TypeError: 变量不是期望的类型时抛出。例如，new 10或'prop' in true。

URIError: 给encodeURI()、encodeURIComponent()、decodeURI()或者decodeURIComponent()等函数传递格式非法的URI字符串时抛出。

理解错误的不同类型可以帮助我们更容易地处理它。所有的错误类型都继承自Error，所以用instanceof Error检查其类型得不到任何有用的信息。通过检查特定的错误类型可以更可靠地处理错误。

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

如果抛出自己的错误，并且是数据类型而不是一个错误，你可以非常轻松地区分自己的错误和浏览器的错误类型的不同。但是，抛出实际类型的错误与抛出其他类型的对象相比，有几大优点。

首先，如上讨论，在浏览器正常错误处理机制中会显示错误消息。其次，浏览器给抛出的Error对象附加了一些额外的信息。这些信息不同浏览器各不相同，但它们为错误提供了如行、列号等上下文信息，在有些浏览器中也提供了堆栈和源代码信息。当然，如果用了Error的构造器，你就丧失了区分自己抛出的错误和浏览器错误的能力。

解决方案就是创建自己的错误类型，让它继承自Error。这种做法允许你提供额外的信息，同时可区别于浏览器抛出的错误。可以用如下的模式来创建自定义的错误类型。

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

这段代码有两个重要的部分：message属性，浏览器必须要知道的错误消息字符串；设置prototype为Error的一个实例，这样对JS引擎而言就标识它是一个错误对象了。接下来就可以抛出一个MyError的实例对象，使得浏览器能像处理原生错误一样做出响应。

throw new MyError('Hello World!');

提醒一下，该方法在IE8和更早的浏览器中不显示错误消息。相反，会看见那个通用的“Exception thrown but not caught”消息。这个方法最大的好处是，自定义错误类型可以检测自己的错误。

try { // 有些代码引发了错误} catch (ex) { if (ex instanceof MyError) { // 处理自己的错误
 } else { // 其他处理
 }
}

如果总是捕获你自己抛出的所有错误，那么IE的那点儿小愚蠢也不足为道了。在一个正确的错误处理系统中获得的好处是巨大的。该方法可以给出更多、更灵活的信息，告知开发者如何正确地处理错误。

相信看了本文案例你已经掌握了方法，更多精彩请关注Gxl网其它相关文章！

推荐阅读：

web开发中如何避免空比较

为什么web开发中需要避免使用全局变量