Taobao FED

聊一聊 JavaScript 中的错误隔离

聊一聊 JavaScript 中的错误隔离

接口请求失败、接口中部分数据缺失、运营数据不符合预期… 当我们的应用发布上线后,就开始面临这些风险。

而一旦这些问题导致了 JavaScript 报错(如空指针异常),并且没有被有效地隔离,就有可能引发页面的白屏、无法交互等线上问题。

在双 11 准备期间,我们收集了过往一年前端相关的线上问题,在收集的 21 个案例中,竟有一半的问题都与「数据异常触发页面显示异常」这个原因有些相关。

如何将错误的影响隔离在一定范围内,显得尤为重要。

这篇文章就和大家一起来聊一聊我们尝试过的一些方案,及遇到的问题。

从空指针异常说起

数据引发的最常见的问题就是空指针异常。

1
var result = a.b.c.d;

这样的代码如同地雷,一旦 a 是一个动态数据,那么问题一触即发。

封装一个 get 的方法来取值,当数据不存在时,返回 undefined,可以快速避免此类问题。

1
var result = get(a, 'b.c.d');

但如同我们期望大家在取值前,都先做判断一样,并不能保证所有人都这么用了,用不用全靠自觉。

1
2
3
if (a && a.b && a.b.c) {
var result = a.b.c.d;
}

所以,有了以下的一些方案:

异步数据校验

对异步数据校验的想法是,在数据获取后、使用前,先做一遍schema校验,检测重要数据缺失、类型不对等异常情况。

与此方案对应的,我们在 fetch 的基础上封装了 fetch-checker注1 组件。

fetch-checker 强制要求用户在请求数据的同时,提供数据对应的 schema:

1
2
3
4
5
6
7
8
9
10
11
12
let schema = {
"rule": {
"type": "string",
},
"banner": {
"type": "object",
"required": true,
"default": {
"url": "https://item.taobao.com/item.htm?id=527331762117"
}
}
};

这份 schema 需要描述:

  • 每个字段的类型
  • 字段是否 required
  • 当 required 的字段缺失时,是否需要打底数据

fetch-checker 在拿到数据后,先做一层校验,如有需要的话,补上缺失的数据,然后再返回给调用者。这样,使用者拿到的数据就一定是符合预期的。

然而,这个方案面临的挑战是:

  1. 如何确保调用者提供了完整的 schema 描述。不想写 schema,完全可以提供一个粗略的 schema 描述,来通过校验。
  2. schema 如何精简。即不会对 bundle 大小造成太大影响,又能满足校验的功能。

代码编译

受 babel 的启发,这个方案是对存在 NPE 隐患的代码,在编译阶段,将其转换成等价的安全代码。如下所示:

1
2
3
4
5
6
7
var a = {};

// input
var result = a.b.c;

// output
var result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;

a 为空对象时,执行编译后的代码会返回 null,从而避免因为代码抛错,阻断后续进程。

babel-plugin-safe-member-expression注2 这个 Babel 插件中,我们做了上述的尝试。目前,cake项目中,已经可以通过 enableSafeMemberExpression 这个配置,选择性的启用该功能。

这个方案相比来说接入成本较低,开发者无需对现有的代码做出调整,但同样存在挑战:

  • 开发阶段问题不易暴露,明明应该报错的场景,却没有任何反馈。理想的状态是:开发调试阶段尽可能多的暴露问题,线上则尽可能的减少报错。
  • 隐患的代码如何界定。目前所有的 a.b 的调用方式都会按上述方案进行编译,虽然测试过程中还没有发现问题,但只处理有隐患的代码才更安全。

静态校验

flow 为代表的静态校验工具,可以在一定程度上检测出 NPE 隐患。

1
2
3
4
5
6
type res = {
data ?: Object
}

let name = res.data.name;
// property `name`. Propery cannot be accessed on possibly undefined value

如上面的代码所描述的,使用者需要首先理清自己的数据是否允许为空值,当 data 被允许为空值时,通过 flow 检测,data.name 类似这样调用便会被检测出错误。

然而,如何来推进所有的业务都接入静态校验,接入后,又如何保证开发者描述了所有的类型,却同样是个难点。

小结

总结以上几种方案,各有优缺点,都还不能算做最理想的解决方案。

方案名称 优势 缺点
提前判断 实行简单 全靠自觉
异步数据校验 可确保所使用的数据是满足预期的 schema 描述成本高
代码编译 接入成本低,易执行 开发阶段不易暴露问题
静态校验 对现有代码逻辑侵入少 落地成本高

对于业务来说,最愿意使用和有效的方案一定是:

  • 能将线上问题隔离在一个小范围内,同时不影响开发调试阶段的问题暴露
  • 能提前暴露出隐患
  • 接入成本低,不需要大量修改现有业务代码

关于空指针异常和错误隔离,机智的你又有哪些方案,一起来讨论吧。

编者注: 本文提到的所有工具如未提供链接,可能是内部代码,暂未对外公布。