前言

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

链接: https://fly63.com/article/detial/1636