JavaScript でのエラーの分離

インターフェースリクエストの失敗、インターフェース内のデータの一部が欠落している、運用データが期待を満たしていない...アプリケーションがリリースされてオンラインになると、私たちはこれらのリスクに直面し始めます。

これらの問題が JavaScript エラー (null ポインター例外など) につながり、効果的に分離されないと、ページ上の白い画面や操作不能などのオンライン問題が発生する可能性があります。

ダブル 11 の準備中に、過去 1 年間にフロントエンド関連のオンラインの問題を収集しました。収集された 21 件のうち、問題の半数は「データの異常によりページ表示の例外が発生する」という理由に関連していました。

エラーの影響を特定の範囲内で切り分ける方法が特に重要です。

この記事では、私たちが試した解決策のいくつかと、遭遇した問題についてお話します。

Null Pointer Exceptionから始まる

データによって引き起こされる最も一般的な問題は、Null Pointer Exceptionです。

var result = a.b.c.d;

このようなコードは、aが動的データになると、問題が発生し始めます。

値を取得するためのgetメソッドをカプセル化すると、データが存在しない場合にはunknownが返されるため、このような問題をすぐに回避できます。

　var result = get(a, 'b.c.d'); 
　但如同我们期望大家在取值前，都先做判断一样，并不能保证所有人都这么用了，用不用全靠自觉。
if (a && a.b && a.b.c) {
        var result = a.b.c.d;
}

したがって、次の解決策があります:

非同期データ検証

非同期データ検証のアイデアは、データ取得後、重要なデータを検出するために使用する前にスキーマ検証を行うことです 欠落例外と型不一致の例外。

このソリューションに対応して、フェッチに基づいてフェッチチェッカー 注 1 コンポーネントをカプセル化しました。

フェッチチェッカーは、データをリクエストするときにユーザーにデータに対応するスキーマを提供するように強制します:

let schema = {
    "rule": {
      "type": "string",
    },
    "banner": {
      "type": "object",
      "required": true,
      "default": {
        "url": "https://item.taobao.com/item.htm?id=527331762117"
      }
    }
};

このスキーマを記述する必要があります:

各フィールドの型

フィールドが必須かどうか

いつrequired フィールドが欠落している場合、データを基にする必要がありますか? fetch-checker はデータを取得した後、必要に応じてまず一定レベルの検証を実行し、それから呼び出し元にデータを返します。このように、ユーザーが取得したデータは期待どおりのものでなければなりません。

しかし、この解決策が直面する課題は次のとおりです:

呼び出し元が完全なスキーマ記述を提供することを保証する方法。スキーマを書きたくない場合は、検証に合格するために大まかなスキーマの説明を入力できます。

スキーマを効率化する方法。つまり、バンドルサイズには大きな影響を与えず、検証機能も満たすことができます。

コードコンパイル

babel からインスピレーションを得たこのソリューションは、コンパイル段階で NPE リスクのあるコードを同等の安全なコードに変換します。以下に示すように:

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 プラグイン babel-plugin-safe-member-expression 注 2 では、上記の試みを行いました。現在、cake プロジェクトでは、enableSafeMemberExpression 設定を通じてこの機能を選択的に有効にすることができます。

このソリューションはそれに比べてアクセスコストが低く、開発者は既存のコードを調整する必要がありませんが、まだ課題があります:

開発段階の問題は簡単には明らかにされず、シナリオに対するフィードバックはありませんエラーを報告する場所。理想的な状態は、開発およびデバッグ段階でできるだけ多くの問題を明らかにし、オンラインでのエラーをできるだけ減らすことです。

隠しコードを定義するにはどうすればよいですか？現時点では、すべての a.b 呼び出しメソッドは上記のスキームに従ってコンパイルされますが、テスト プロセス中に問題は見つかりませんでしたが、隠れた危険性のあるコードのみを扱う方が安全です。

静的検証

　　以 flow 为代表的静态校验工具，可以在一定程度上检测出 NPE 隐患。
type res = {
        data ?: Object
}
let name = res.data.name;
// property `name`. Propery cannot be accessed on possibly undefined value

上記のコードで説明したように、ユーザーはまずデータが null であることが許可されているかどうかを明確にする必要があります。データが null であることが許可されている場合は、data.name のような呼び出しを通じて検出されます。これによりエラーが検出されます。

ただし、すべての企業が静的検証にアクセスできるように促進する方法や、アクセス後に開発者がすべてのタイプを記述していることを確認する方法も困難です。

上記は JavaScript でのエラー分離の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。