聊一聊 JavaScript 中的错误隔离

1932723078 8年前
   <p><img src="https://simg.open-open.com/show/ffc3ac3723fcdd779398394d463010a2.jpg"></p>    <p>接口请求失败、接口中部分数据缺失、运营数据不符合预期… 当我们的应用发布上线后,就开始面临这些风险。</p>    <p>而一旦这些问题导致了 JavaScript 报错(如空指针异常),并且没有被有效地隔离,就有可能引发页面的白屏、无法交互等线上问题。</p>    <p>在双 11 准备期间,我们收集了过往一年前端相关的线上问题,在收集的 21 个案例中,竟有一半的问题都与「数据异常触发页面显示异常」这个原因有些相关。</p>    <p>如何将错误的影响隔离在一定范围内,显得尤为重要。</p>    <p>这篇文章就和大家一起来聊一聊我们尝试过的一些方案,及遇到的问题。</p>    <h3><strong>从空指针异常说起</strong></h3>    <p>数据引发的最常见的问题就是空指针异常。</p>    <pre>  <code class="language-javascript">var result = a.b.c.d;  </code></pre>    <p>这样的代码如同地雷,一旦 a 是一个动态数据,那么问题一触即发。</p>    <p>封装一个 get 的方法来取值,当数据不存在时,返回 undefined ,可以快速避免此类问题。</p>    <pre>  <code class="language-javascript">var result = get(a, 'b.c.d');  </code></pre>    <p>但如同我们期望大家在取值前,都先做判断一样,并不能保证所有人都这么用了,用不用全靠自觉。</p>    <pre>  <code class="language-javascript">if (a && a.b && a.b.c) {   var result = a.b.c.d;  }  </code></pre>    <p>所以,有了以下的一些方案:</p>    <h3><strong>异步数据校验</strong></h3>    <p>对异步数据校验的想法是,在数据获取后、使用前,先做一遍schema校验,检测重要数据缺失、类型不对等异常情况。</p>    <p>与此方案对应的,我们在 fetch 的基础上封装了 fetch-checker <sup>注1</sup> 组件。</p>    <p>fetch-checker 强制要求用户在请求数据的同时,提供数据对应的 schema:</p>    <pre>  <code class="language-javascript">let schema = {      "rule": {        "type": "string",      },      "banner": {        "type": "object",        "required": true,        "default": {          "url": "https://item.taobao.com/item.htm?id=527331762117"        }      }  };  </code></pre>    <p>这份 schema 需要描述:</p>    <ul>     <li>每个字段的类型</li>     <li>字段是否 required</li>     <li>当 required 的字段缺失时,是否需要打底数据</li>    </ul>    <p>fetch-checker 在拿到数据后,先做一层校验,如有需要的话,补上缺失的数据,然后再返回给调用者。这样,使用者拿到的数据就一定是符合预期的。</p>    <p>然而,这个方案面临的挑战是:</p>    <ol>     <li>如何确保调用者提供了完整的 schema 描述。不想写 schema,完全可以提供一个粗略的 schema 描述,来通过校验。</li>     <li>schema 如何精简。即不会对 bundle 大小造成太大影响,又能满足校验的功能。</li>    </ol>    <h3><strong>代码编译</strong></h3>    <p>受 babel 的启发,这个方案是对存在 NPE 隐患的代码,在编译阶段,将其转换成等价的安全代码。如下所示:</p>    <pre>  <code class="language-javascript">var a = {};    // input  var result = a.b.c;    // output  var result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;  </code></pre>    <p>当 a 为空对象时,执行编译后的代码会返回 null ,从而避免因为代码抛错,阻断后续进程。</p>    <p>在 babel-plugin-safe-member-expression <sup>注2</sup> 这个 Babel 插件中,我们做了上述的尝试。目前,cake项目中,已经可以通过 enableSafeMemberExpression 这个配置,选择性的启用该功能。</p>    <p>这个方案相比来说接入成本较低,开发者无需对现有的代码做出调整,但同样存在挑战:</p>    <ul>     <li>开发阶段问题不易暴露,明明应该报错的场景,却没有任何反馈。理想的状态是:开发调试阶段尽可能多的暴露问题,线上则尽可能的减少报错。</li>     <li>隐患的代码如何界定。目前所有的 a.b 的调用方式都会按上述方案进行编译,虽然测试过程中还没有发现问题,但只处理有隐患的代码才更安全。</li>    </ul>    <h3><strong>静态校验</strong></h3>    <p>以 flow 为代表的静态校验工具,可以在一定程度上检测出 NPE 隐患。</p>    <pre>  <code class="language-javascript">type res = {   data ?: Object  }    let name = res.data.name;  // property `name`. Propery cannot be accessed on possibly undefined value  </code></pre>    <p>如上面的代码所描述的,使用者需要首先理清自己的数据是否允许为空值,当 data 被允许为空值时,通过 flow 检测, data.name 类似这样调用便会被检测出错误。</p>    <p>然而,如何来推进所有的业务都接入静态校验,接入后,又如何保证开发者描述了所有的类型,却同样是个难点。</p>    <h3><strong>小结</strong></h3>    <p>总结以上几种方案,各有优缺点,都还不能算做最理想的解决方案。</p>    <table>     <thead>      <tr>       <th>方案名称</th>       <th>优势</th>       <th>缺点</th>      </tr>     </thead>     <tbody>      <tr>       <td>提前判断</td>       <td>实行简单</td>       <td>全靠自觉</td>      </tr>      <tr>       <td>异步数据校验</td>       <td>可确保所使用的数据是满足预期的</td>       <td>schema 描述成本高</td>      </tr>      <tr>       <td>代码编译</td>       <td>接入成本低,易执行</td>       <td>开发阶段不易暴露问题</td>      </tr>      <tr>       <td>静态校验</td>       <td>对现有代码逻辑侵入少</td>       <td>落地成本高</td>      </tr>     </tbody>    </table>    <p>对于业务来说,最愿意使用和有效的方案一定是:</p>    <ul>     <li>能将线上问题隔离在一个小范围内,同时不影响开发调试阶段的问题暴露</li>     <li>能提前暴露出隐患</li>     <li>接入成本低,不需要大量修改现有业务代码</li>    </ul>    <p>关于空指针异常和错误隔离,机智的你又有哪些方案,一起来讨论吧。</p>    <p> </p>    <p>来自:http://taobaofed.org/blog/2016/11/10/prevent-prop-access-error-in-js/</p>    <p> </p>