JavaScript try-catch实战：兜底处理与场景化错误包装

控制流与数据流基础

程序按顺序从上到下执行，但可通过控制语句改变执行路径。受这些语句影响，程序最终执行的路线被称为控制流。

JavaScript中的控制语句包括if、for、while以及try-catch等，它们均能改变程序的执行走向。

程序的核心是对数据进行操作，随着控制流的推进，数据随之发生变化，这种数据的变化过程被称为数据流。

显然，数据流依赖于控制流，因此在程序分析中，数据流分析需建立在控制流分析的基础之上。

参考以下代码示例：


const a = 1;
let b;

if (a === 1) {
    b = '1111';
} else {
    b = '2222';
}

由于变量a的值为1，程序会执行到b = '1111';这一行。这体现了控制流，即程序最终执行的代码路径，可用于分析程序走向及进行死代码删除等优化。

随着控制流的执行，变量b被赋值为'2222'，这构成了数据流，即值的变化过程，可用于分析特定语句中变量的值。

程序针对不同数据执行不同处理，若数据存在错误（如为空或格式不对），处理程序将无法继续，导致报错并中断后续控制流。此时，需通过try-catch进行错误处理，即异常处理。

进行异常处理主要出于两个目的：

第一，对出错的逻辑进行兜底处理。

例如，当参数解析出错时，可在catch块中赋予默认值。这种处理旨在避免错误再次抛出。在此场景下，try-catch作为逻辑的一部分，其作用类似于if-else。

第二，对抛出的错误进行更具场景化的描述。

JavaScript的报错由JS引擎抛出，例如调用null对象的方法会引发TypeError，使用未声明的变量会引发ReferenceError。

具体的Error在不同场景下具有不同含义：

若该对象源自用户输入，则表明用户输入有误；若源自服务端获取，则意味着服务端返回数据有误。在不同场景下，同一Error具有更具体的含义，因此需通过try-catch捕获后，抛出一个包含场景信息的自定义错误。

许多库和框架在此方面表现良好，抛出的错误包含具体场景信息，甚至提供解决方案，部分还通过错误编号（errorno）进行管理，便于查询解决方式。这属于对错误的自定义处理。

相比之下，许多业务代码直接抛出原生Error。虽然异常监控平台能收集全局抛出的错误，但这些错误往往信息原始，仅包含错误位置和堆栈，仍需通过查看源码来定位问题。

例如，若抛出一个对象为空的错误，若不进行自定义处理，我们无法得知是哪个对象为空、原因及解决方法，甚至是否有相关编号。

若能在catch各种错误后，抛出包含具体场景信息的自定义错误，将极大提升问题排查效率。第三方库通常做得较好，而业务代码中较少有人注重此类场景化的自定义错误处理。

前端业务代码的用户通过界面使用软件，因此只需对错误进行UI提示即可。而库的代码面向开发者，需对错误进行场景化描述，甚至提供错误编号及解决方案。

笔者认为，业务代码也应像第三方库那样对待错误，避免抛出无意义的原生错误，转而抛出具有具体含义的自定义错误，从而简化问题的排查与解决。

然而，场景化的自定义错误需建立在对代码可能抛出的错误有充分把握的基础上。若自定义错误信息与实际原因不符，反而会增加排查难度，此时直接抛出原生错误或许更为合适。

总结

程序执行流程为控制流，受控制语句影响；执行过程中数据发生变化，称为数据流。控制流和数据流是程序分析中常关注的两个方面。

错误会中断控制流，需通过try-catch进行处理。

错误处理有两个主要目的：

一是进行兜底处理，类似于if-else，无需再次抛出错误。

二是对原生JavaScript错误进行场景化描述，创建包含更具体信息的错误对象并抛出。

许多库在此方面表现优异，甚至提供错误编号及解决方案。但业务代码多仅向用户展示UI反馈，未对抛出的错误进行场景化包装。这导致错误监控平台收集到的错误较为原始，需查看源码排查。若业务代码也能像库代码那样进行场景化错误包装，统计与排查问题将更为容易，然而大多数JavaScript工程师尚未做到这一点。

本文介绍了JavaScript中try-catch的作用，更多相关内容请搜索本站以前的文章或继续浏览下面的相关文章，希望大家以后多多支持本站！