慎用try catch
前言
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://segmentfault.com/a/1190000017409108
本文内容仅供个人学习/研究/参考使用，不构成任何决策建议或专业指导。分享/转载时请标明原文来源，同时请勿将内容用于商业售卖、虚假宣传等非学习用途哦～感谢您的理解与支持！
