程序是从上到下顺序执行的，同时可以通过一些控制语句来改变执行的路线，受控制语句影响下，程序最终的执行路线就是控制流。
js 里面的控制语句有 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。
- 对报的错做更场景化的描述。
JS 的报错是 JS 引擎抛出的，比如调用了一个 null 对象的方法会报 TypeError，使用了未声明的变量会报 ReferenceError。而具体的 Error 是在不同场景下报出的，就有不同的含义：
如果这个对象是来自用户输入的，那就是用户输入的有错误，如果这个对象是从服务端获取的，那就意味着服务端返回的数据有错误。在不同的场景下，同一个 Error 会有更具体的含义，所以我们要做 try catch。然后抛出一个自定义的错误，包含有场景信息的错误描述。
这点很多库和框架做的都比较好，报出的错都是有具体的场景信息，甚至还有解决方式，而且还有的通过错误编号做了管理，可以通过 errorno 来查询解决方式。这种就是对错误做了自定义的处理。
而很多业务代码中报的错就并没有做这种处理，是直接把原生 Error 给报出来了。我们会通过异常监控平台来收集一些 throw 到全局的错误，而这些错误往往都是比较原始的信息，虽然带上了错误位置和堆栈，但还要通过看源码来定位问题。
比如报了一个对象为空的错误，但是我怎么知道这是什么对象为空，会是什么原因，怎么解决，有没有编号。
如果我们能够对各种错误 catch 之后 throw 出一些具体场景的自定义错误，那是不是就好的多了。这点第三方库都做得很好，而业务代码很少有人注重场景化的自定义错误。
当然，前端业务代码的用户是通过界面来使用该软件的，其实只要对各种错误做一些 UI 上的提示就可以。而库的代码是给开发者用的，那么就要对各种错误做场景化的描述，甚至给错误编号并给出解决方案。
但我觉得业务代码也应该像第三方库代码那样来对待错误，不要把没有啥意义的原生错误报出来，而是报一些有具体含义的自定义错误，这样排查和解决问题就会简单很多。
不过虽然场景化的自定义错误可以更好的帮助排查问题，那也一定是建立在对该段代码可能报的错误有把握的情况下。要是自己报出的错误信息和实际的错误原因不一样，反而会增加排查问题的难度，还不如把原生错误报出来。
总结
程序执行的流程是控制流，受控制语句影响，执行的过程中会改变数据，数据的变化叫做数据流，控制流和数据流是程序分析里面经常分析的两个方面。
错误会中断控制流，我们要对错误做一些处理，通过 try catch。
错误处理有两个目的：
一个是做一些兜底的处理，相当于 if else，不需要再把错误报出来。
一个是做对原生的 JS 错误做场景化的描述，创建一个有更具体信息的错误对象抛出来。
这点很多库做的很好，甚至还会给错误编号并给出解决方式。但业务代码其实很多只做了给用户的 UI 上的反馈，没有对抛出的错误做场景化的包装。这就导致了错误监控平台收集到的错误都是比较原始的错误，需要查看源码来排查。如果也能像库的代码那样做一些场景化的错误包装，统计和排查起问题来会容易很多，这点大多数 Javascript 工程师都没做到。
