纯牛奶645
纯牛奶645
  • 发布:2018-02-11 10:18
  • 更新:2018-02-11 10:18
  • 阅读:2759

js的try catch

分类:Native.js
js

jquery 让 dom 操作不报错,结果现在很多前端以为 try catch 都用不着了。
https://github.com/inexorabletash/polyfill/blob/master/es5.js
这里有个例子,通过try catch 监测浏览器是否实现某个功能是个好习惯,如果不支持,有时候可以采用降级处理。
那些不处理的异常的,估计也就写写网页吧,一个严肃的应用出现js报错是非常影响用户体验的事情!

如果你无法降级处理,做法也不应该是直接抛出异常,好的体验应该是告诉用户你的应用部分功能不支持他现在的浏览器,提示他更换,抛错会让用户无所适从。
下面用符合 ECMAscript 规范的简单的 JavaScript 来编写相同的“条件catch子句”(显然更加冗长的,但是可以在任何地方运行):
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Statements/try...catch
try {
myroutine(); // may throw three types of exceptions
} catch (e) {
if (e instanceof TypeError) {
// statements to handle TypeError exceptions
} else if (e instanceof RangeError) {
// statements to handle RangeError exceptions
} else if (e instanceof EvalError) {
// statements to handle EvalError exceptions
} else {
// statements to handle any unspecified exceptions
logMyErrors(e); // pass exception object to error handler
}
}

try{
//正常执行
}catch(e/你感觉会出错的 错误类型/){
//可能出现的意外
e.g:用户自己操作失误 或者 函数少条件不影响下面的函数执行
//有时也会用在 比如focus()但ie有可能会第一次没有focus事件 再让他执行一次
//有时一些不是bug的bug 在ie上要求必须加上catch,哪怕就一个空catch
}

try catch的使用,永远应该放在你的控制范围之内,而不应该防范未知的错误。也就是说你很清楚知道这里 是有可能“出错的”,而且你很清楚知道什么前提下会出错,你就是要故意利用报错信息来区分错误,后续的程序会解决所有的出错,让程序继续执行。
不能让用户发现你根本没预料到的错误,而不是你先发现错误。
大多数情况下,try catch适用于两种场合:
1、浏览器原罪的场合:也就是兼容性场合,因为浏览器兼容性不是程序员能改正的,所以只能try catch:由于不同浏览器的报错提示是不一样的,根据捕获的浏览器的报错提示判断用户的浏览器,然后做出对应的措施,这时候使用try catch是巧妙的办法,如果用if就比较笨拙,因为if通常只能反馈真或假,不能直接反馈浏览器的报错内容。
2、考虑如下代码。window.a.b是非法的,再跟2对比就没有意义,这样非法的条件,在try catch中仍可以继续运行下去。但在if中window.a.b已经报错,整个页面都会坏掉。如果希望用if写,那么必须先判断window.a是否是合法的,window.a是合法的前提下再判断window.a.b是不是合法的,如果也是合法的,再判断window.a.b是否不等于2,这样是不是很蠢?这时就体现出try catch的妙处了,程序不但知道window.a.b !== 2是假的,而且直接可以知道究竟哪一步就已经是假的。
再想象一下,有一个变量是json.a.b.c,其中的a/b/c都可能是存在的也可能是不存在的,全看具体情况,这时候你简单的写if (json.a.b.c === 2) {...}是不行的,因为json.a.b就可能已经是非法的,所以你如果用if,就要考虑a是不是非法的、a是合法前提下b是不是非法的,b是合法前提下c是不是非法的。但是json.a.b.c === 2在try中就可以直接写,也就是说,我不关心究竟a/b/c谁是非法的,我只关心json.a.b.c到底是不是等于2,不等于2或者任何一步出错,对我来讲没有区别,反正都是不等于2,我不关心哪步出错,而且程序不会坏掉。这是一种比较省心的写法。
另外注意,**try catch不能做真假判断,只能做非法判断。也就是说:try {1 === 2},虽然1===2是假,但是是合法的,catch不会捕捉到错误,也不会告诉你1 === 2到底是真是假。**所以,写在try里的应该是json.a.b.c而不是json.a.b.c === 2。究竟是不是等于2,是后面的事,是if干的事。简单说,try catch用于捕捉报错,当你不关心哪一步错误,只关心有没有错,就用try catch。
try{
window.a.b !== 2;
}catch(err){
alert(err) //可执行
alert(123)//可执行
}

if(window.a.b !== 2){
alert("error") //不执行
}
alert(123) //不执行
try catch在早期被各种语言的程序员滥用,try catch出现的场合就被夸大了,事实上没那么多适用场合。如果你的几千行程序都没用到try catch也是很正常的,尤其是用了jquery。
2.
1.事情还有得挽回,换条路走
try {
执行某个逻辑
} catch(e){
出问题了,换个逻辑执行
}
2.体面的退出
try{
正常流程
}catch(e){
弹个框告诉用户不好意思处理点问题
如果是用户的错误就告诉用户什么地方错了
如果是程序的错,就告诉用户不好意思没法执行
}
3.
异常处理和错误处理是两个不同的概念。例如NodeJS里大多数error都是用来处理异常的,因为异常是不可避免的,例如:数据库挂了,网络错误,你虽然知道有可能,但是不知道何时发生,这些异常你需要捕捉或者传给上层。而错误处理,这是一些基本的判定,可以从代码级别避免其发生,可预知可推测,如果发生了,不是系统问题,而是你的程序有bug了。
对于NodeJS来说,两种错误都时刻需要注意,特别是系统错误,因为不可预知,需要大量代码来catch错误,传递错误,最后统一处理。
而对于前端,系统错误出现的场景相对来说低得多,主要是一些i/o场景,大部分前端可能不太关心。而普通的错误处理,则比较常见,因为前端耦合的特定系统比较多,和这些系统操作的时候,数据和dom大多是可预知的,跟系统错误还是要区分开的,一些错误,需要你自己去吞并和处理,如果出现错误,显然是bug,而不是不可预知。

一句话解释:
try catch机制非常好。那些觉得try catch不行的人,是他们自己的水平有问题,无法理解这种机制。并且这群人写代码不遵守规则,喜欢偷懒,这才造成try catch不好的错觉。
详细解释:
1.程序要健壮,必须要设计报错机制。
最古老,也是最常见的,比如:
bool CreateFile( );
//如果创建文件失败就返回false,否则返回true。
这种报错方式,显然不好。因为它没有给出产生错误的具体原因。
2.改进:一个函数或过程,会因为不同的原因产生错误,报错机制必须要把这些错误原因进行区分后,再汇报。
比如:
int CreateFile():
//如果创建成功就返回1.
//如果是因为没有权限,导致失败,返回-1。
//如果是因为文件已经存在,导致失败,返回-2。
//如果是因为创建文件发生超时,导致失败,返回-3。
这样看上去,比【1】要好些,至少指出了比较具体的失败原因,但是,还不够。
3.很多情况下,函数需要把详细的原因,用字符串的方式,返回:
class Result{
....int State;//同【2】
....string ErrorMessage;//如果失败,这里将给出详细的信息,如果有可能,应该把建议也写上去。
}
Result CreateFile();
//如果创建成功,返回的Result,State为1,ErrorMessage为null。
//如果是因为没有权限,导致失败,返回的Result,State为-1,ErrorMessage为"用户【guest】没有权限在【C:\】这个目录下创建该文件。建议您向管理员申请权限,或者更换具有权限的用户。"。//如果是因为文件已经存在,导致失败,返回的Result,State为-2,ErrorMessage为"文件【C:\abc.txt】已经存在。如果需要覆盖,请添加参数:arg_overwrite = true"。//如果是因为创建文件发生超时,导致失败,返回的Result,State为-3,ErrorMessage为"在创建文件时超时,请使用chkdsk检查文件系统是否存在问题。"。

4.我个人推崇上面这种方式,完整,美观。但是这种流程,容易与正常的代码混在一起,不好区分开。因此,Java、C#等设计了try catch这一种特殊的方式:void CreateFile()//如果创建成功就不会抛出异常。//如果是因为没有权限,导致失败,会抛出AccessException,这个Exception的Msg属性为"用户【guest】没有权限在【C:\】这个目录下创建该文件。建议您向管理员申请权限,或者更换具有权限的用户。"。//如果是因为文件已经存在,导致失败,会抛出FileExistedException,这个Exception的Msg属性为"文件【C:\abc.txt】已经存在。如果需要覆盖,请添加参数:arg_overwrite = true"。//如果是因为创建文件发生超时,导致失败,会抛出TimeoutException,这个Exception的Msg属性为"在创建文件时超时,请使用chkdsk检查文件系统是否存在问题。"。可见,上述机制,实际上是用不同的Exception代替了【3】的State。
这种机制,在外层使用时:
try{
....CreateFile( "C:\abc.txt" );
}catch( AccessException e ){
....//代码进入这里说明发生【没有权限错误】
}
catch( FileExistedException e )
{
....//代码进入这里说明发生【文件已经存在错误】
}catch( TimeoutException e ){
....//代码进入这里说明发生【超时错误】
}
对比一下【3】,其实这与【3】本质相同,只是写法不同而已。
5.综上,我个人喜欢【3】这类面向过程的写法。但很多喜欢面向对象的朋友,估计更喜欢【4】的写法。然而【3】与【4】都一样。这两种机制都是优秀的错误处理机制。
6. 理论说完了,回到正题,题注问:为什么不用try catch?
这是因为,很多新手,他们是这样写代码的:
void CreateFile( )
//无论遇到什么错误,就抛一个 Exception,并且也不给出Msg信息。
这样的话,在外层只能使用:
try
{
....CreateFile( "C:\abc.txt" );
}
catch( Exception e )
{
....//代码进入这里说明发生错误
}
当出错后,只知道它出错了,并不知道是什么原因导致错误。这同【1】。

以及,即使CreateFile是按【4】的规则设计的,但新手在外层是这样使用的:
try
{
....CreateFile( "C:\abc.txt" );
}
catch( Exception e )
{
....//代码进入这里说明发生错误
....throw Exception( "发生错误" )
}
这种情况下,如果这位新手的同事,调用了这段代码,或者用户看到这个错误信息,也只能知道发生了错误,但并不清楚错误的原因。这与【1】是相同的。出于这些原因,新手的同事,以及用户,并没有想到,造成这个问题是原因新手的水平太差,写代码图简单省事。他们却以为是try catch机制不行。因此,这就导致了不建议用try catch。
<script language="JavaScript">
try
{
throw new Error(10,"asdasdasd")
}
catch (e)
{
alert(e.message);
alert(e.description)
alert(e.number)
alert(e.name)
throw new Error(10,"asdasdasd")
}

</script>
在JavaScript可以使用try...catch来进行异常处理。例如:
try {
foo.bar();
} catch (e) {
alert(e.name + ": " + e.message);
}
目前我们可能得到的系统异常主要包含以下6种:
EvalError: raised when an error occurs executing code in eval()
RangeError: raised when a numeric variable or parameter is outside of its valid range
ReferenceError: raised when de-referencing an invalid reference
SyntaxError: raised when a syntax error occurs while parsing code in eval()
TypeError: raised when a variable or parameter is not a valid type
URIError: raised when encodeURI() or decodeURI() are passed invalid parameters
上面的六种异常对象都继承自Error对象。他们都支持以下两种构造方法:
new Error();
new Error("异常信息");
手工抛出异常的方法如下:
try {
throw new Error("Whoops!");
} catch (e) {
alert(e.name + ": " + e.message);
}
如要判断异常信息的类型,可在catch中进行判断:
try {
foo.bar();
} catch (e) {
if (e instanceof EvalError) {
alert(e.name + ":" + e.message);
}
else if (e instanceof RangeError) {
alert(e.name + ": " + e.message);
}
// etc
}
Error具有下面一些主要属性:

description: 错误描述 (仅IE可用).
fileName: 出错的文件名 (仅Mozilla可用).
lineNumber: 出错的行数 (仅Mozilla可用).
message: 错误信息 (在IE下同description)
name: 错误类型.
number: 错误代码 (仅IE可用).
stack: 像Java中的Stack Trace一样的错误堆栈信息 (仅Mozilla可用).
因此为了更好的了解错误信息我们可以将catch部分改为如下形式:
try {
foo.bar();
} catch (e) {
if (browserType != BROWSER_IE) {
alert("name: " + e.name +
"message: " + e.message +
"lineNumber: " + e.lineNumber +
"fileName: " + e.fileName +
"stack: " + e.stack);
}
else {
alert("name: " + e.name +
"errorNumber: " + (e.number & 0xFFFF ) +
"message: " + e.message");
}
}
JavaScript中的throw命令事实上可以抛出任何对象,并且我们可以在catch接受到此对象。例如:
try {
throw new Date(); // 抛出当前时间对象
} catch (e) {
alert(e.toLocaleString()); // 使用本地格式显示当前时间
}

之前一直没有去研究try catch对代码运行的性能影响,只是一直停留在了感觉上,正好最近开会交流学习的时候,有人提出了相关的问题。借着周末,正好研究一番。
window.JSTracker=window.JSTracker||[];
try{
//your code
}catch(e){
JSTracker.push(e);
throwe;//建议将错误再次抛出,避免测试无法发现异常
}
设计实验方式
简单的设计方案也就是对比实验。
空白组1:[无 try catch 的情况下对数据取模1千万次耗时]
<!DOCTYPEhtml>
<html>
<head>
<title>1无trycatch的情况耗时</title>
<script>
!function(){
//无try catch的情况耗时
var t = newDate();
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
document.write(newDate()–t);
}();
</script>
</head>
<body>
</body>
</html>
参照组2:[将耗时代码用 try 包围,内联耗时代码]
<!DOCTYPEhtml>
<html>
<head>
<title>2在try中内联代码的耗时情况</title>
<script>
!function(){
//在 try 中内联代码的耗时情况
vart=newDate();
try{
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
thrownewError();
}catch(e){
}
document.write(newDate()–t);
}();
</script>
</head>
<body>
</body>
</html>
参照组3:[将耗时代码用 try 包围,外联耗时代码]
?
<!DOCTYPEhtml>
<html>
<head>
<title>3在try中内联代码的耗时情况</title>
<script>
!function(){
functionrun(){
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
}
//在 try 中内联代码的耗时情况
vart=newDate();
try{
run();
thrownewError();
}catch(e){
}
document.write(newDate()–t);
}();
</script>
</head>
<body>
</body>
</html>
参照组4:[将耗时代码用 catch 包围,内联耗时代码]
?
<!DOCTYPEhtml>
<html>
<head>
<title>4在catch中内联代码的耗时情况</title>
<script>
!function(){
//在 catch 中内联代码的耗时情况
vart=newDate();
try{
thrownewError();
}catch(e){
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
}
document.write(newDate()–t);
}();
</script>
</head>
<body>
</body>
</html>
参照组5:[将耗时代码用 catch 包围,外联耗时代码]
?
<!DOCTYPEhtml>
<html>
<head>
<title>5在catch中内联代码的耗时情况</title>
<script>
!function(){
functionrun(){
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
}
//在 catch 中内联代码的耗时情况
vart=newDate();
try{
thrownewError();
}catch(e){
run();
}
document.write(newDate()–t);
}();
</script>
</head>
<body>
</body>
</html>
运行结果(只选取了 Chrome 作为示例)
– 不使用 TRY-CATCH TRY 中耗时,内联代码 TRY 中耗时,外联代码 CATCH 中耗时,内联代码 CATCH 中耗时,外联代码
Chrome51 98.2 1026.9 107.7 1028.5 105.9
给出总结
使用 try catch 的使用无论是在 try 中的代码还是在 catch 中的代码性能消耗都是一样的。
需要注意的性能消耗在于 try catch 中不要直接塞进去太多的代码(声明太多的变量),最好是吧所有要执行的代码放在另一个 function 中,通过调用这个 function 来执行。
针对第二点,可以查看 ECMA 中关于 try catch 的解释,在代码进入 try catch 的时候 js引擎会拷贝当前的词法环境,拷贝的其实就是当前 scope 下的所有的变量。
建议
在使用 try catch 的时候尽量把 try catch 放在一个相对干净的 scope 中,同时在 try catch 语句中也尽量保证足够少的变量,最好通过函数调用方式来 try catch。
试验中的现象解释
测试过程中还是发现了一个疑问, 以下两段代码在 Chrome 44 中运行出来的结果差距非常大,加了一句空的 try catch 之后平均为:850ms,加上之前为:140ms。
?

!function(){
//无 try catch 的情况耗时
vart=newDate();
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
document.write(newDate()–t);
try{
}catch(e){
}
}();
!function(){
//无 try catch 的情况耗时
vart=newDate();
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
document.write(newDate()–t);
}();
其实原因很简单
只要把代码改为这样 耗时就降下来了:
?

!function(){
!function(){
//无 try catch 的情况耗时
vart=newDate();
//耗时代码开始
for(vari=0;i<100000000;i++){
varp=i%2;
}
//耗时代码结束
document.write(newDate()–t);
}();
try{
}catch(e){
}
}();
总结
以上就是关于使用try catch对代码运行性能影响的全部内容。
来源:http://www.jb51.net/article/101291.htm

0 关注 分享

要回复文章请先登录注册