前言:在前一篇文章里,我们整理总结了asp.net服务端的异常处理。这一篇接着前文,简单总结并讨论一下javascript在客户端的异常处理。这样asp.net的服务端和客户端异常处理我们就都有了初步的认识。
1、烦人的脚本错误
楼猪经常装13,但是普遍都没有深度。偶然艰难地看懂了一段英文,终于可以深沉地再装一回:
上面这段话,哼哼,看不懂了吧?nc楼猪优雅且粗暴地理解一下就是,打开一个网页,我们都不时碰到过网页弹出脚步错误并询问“是否要调试?”这种sb问题。烦不烦啊,正常用户经常都会习惯性选择右上红叉,但是这种提示信息可能对开发人员就tmd很有用。由此可见,我kao,开发人员不正常?!看来楼猪理解有误。其实您不难看出,原文要告诉我们的最终意图应该是,网页里出现脚本错误很要命,用户体验不好,白白“吓跑”一批潜在用户。
2、如何处理脚本错误
在js中,我们通常也是通过try...catch 来捕获并处理异常。
try
{
// Run some code here
}
catch (e)
{
// Handle errors here
}
在实际代码中,我们可能会这么写:
var txt = "" ;
try {
alert(aaa); // aaa是未声明的变量
}
catch (e){
txt = " There was an error on this page.\n\n " ;
txt += " Error message: " + e.message + " \n\n " ;
txt += " Error description: " + e.description + " \n\n " ;
txt += " Error name: " + e.name + " \n\n " ;
// alert(txt);//正式平台上可能需要注释掉该行
}
}
还有一种比较通用的做法就是,给window对象的onerror事件注册通用处理方法,并将下面的代码置于页面的<head></head>节内:
return true ;
}
上面这种方式的好处是页面里写一次,就不会弹出恼人的脚本错误,有点全局处理的意思。对于开发人员,这种写法可能会隐藏潜在的脚本错误而不被发现,所以测试的时候需要注释掉上面的函数。
3、javascript里的Error
(1)、Error对象的常用属性
在我们捕获异常的时候,通常都会在catch处抛出一个Error对象的实例e,e的几个常用属性如下:
description 异常的描述信息
message 异常的描述信息
name 异常类型
number 独有的异常代号
在实际开发中,通常都会提示给开发人员message和name信息,以便有针对性地处理异常。
(2)、Error对象的类型
通过(1)中的name属性我们可以查看到异常类型。在js中,有如下几种常见异常类型:
SyntaxError : 在解析js代码时其中的语法错误引发,比如服务端注册脚步,少一个括号或引号等;
ReferenceError : 使用一个无效的引用时引发该异常;
EvalError : 在错误的调用eval函数时引发;
RangeError : 在一个数字型变量的值超出了其范围时引发;
URIError : 错误地使用encodeURI()或decodeURI()函数时引发。
在实际的开发中,针对不同类型的异常作出不同的异常处理,有利于我们有效地发现问题和提高用户体验。
最后多说几句闲话。上周周末休息的时候稍微review了下自己很久以前写的某一个javascript脚本文件。洋洋洒洒几百行代码,自以为写的还是很不错的,但是竟然没有看到一个对异常的处理,心头很沉痛,有种深深的罪恶感(维护这部分代码的童鞋,当你们在眼花缭乱千姿百态的英文单词(或它们的简写)或乱七八糟的拼音(或它们的简写)中穿梭调试时,楼猪虔诚地祝福你们,请你们保重身体啊)。于是故技重施,用“没有人天生就是十全十美的”来安慰一下自己有点受伤的小心灵,但是依然无法使自己心安理得。多事的楼猪又“老奸巨猾”地问了一下和楼猪住在一起的某位it男,他老人家一边看电影一边慢条斯理很不屑地说他从不知道客户端还可以写try...catch云云......此言一出,nc楼猪的脑袋里似乎有一个激动的声音在呐喊:救星,大救星,很好,非常好,实在是太好了,好不容易终于让自己的心里稍微平衡了一下(一不小心又暴露楼猪心里太阴暗了,面壁去也)。
BTW,现在回想他回答问题的口气,嗯,漫不经心的,不会是糊弄楼猪,一不小心恰好“故意”安慰楼猪的吧?
今天才是愚人节呢。