前言ECMA-262第3版引入了try catch语句，作为JavaScript中处理异常的一种标准方式。基本的语法如下所示。但是在前端js代码中很少看到try catch语句,并不是所以代码都需要加try catch来作得不偿失的“保险”，下面来分析作为前端代码，哪些地方才需要真正加try catch。一、try catch语法try { //可能会导致错误的代码} catch (error) { //在错误发生时怎么处理}finally { //即使报错始终执行 }二、try catch缺点1.try catch耗性能众所周知，js以一个大括号{}决定一个块级作用域，代码进入 try catch 的时候 js引擎会拷贝当前的词法环境，拷贝的其实就是当前 scope 下的所有的变量，这样消耗的性能是很大的，性能消耗与try catch代码量以及变量成正比。2.try catch捕获不到异步错误尝试对异步方法进行try catch操作只能捕获当次事件循环内的异常，对call back执行时抛出的异常将无能为力。try { setTimeout(()=>{ const A = 1 A = 2 },0)} catch (e) { // 这里并不能捕获回调里面抛出的异常 console.log("—–catch error——") console.log(e)}3.try catch可能会导致报错点更模糊try catch语句中报错直接到catch中处理，而浏览器控制台看不到报错信息。但很多人并没有在catch中抛出报错信息，或改写成自己随意写的报错文言，这样其实不如直接看浏览器原生的报错修改bug更方便。三、try catch总结说了这么多try catch的缺点，有些小伙伴们就会奇怪到里那里用try catch比较合适呢？try catch最适合处理那些我们无法控制的错误，如I/O操作，后端java读取I/O操作比较多比如读数据库，所以用try catch比较多。前端可以用在上传图片或async await同步调接口。async function f() { try { await Promise.reject(‘出错了’); } catch(e) { } return await Promise.resolve(‘hello world’);}但是大部分前端代码处理都不怎么依赖环境也没有I/O操作，都是自己写的代码，在明明白白地知道自己的代码会发生错误时，再使用try catch语句就不太合适了，所以慎用try catch。参考资料https://raoenhui.github.io/js/2018/12/16/tryCatch/index.htmlhttps://www.jb51.net/article/101291.htmhttp://es6.ruanyifeng.com/#docs/asyncHappy coding .. :)