web-dev-qa-db-ja.com

Facebookの不変条件とスローの場合の使用

私はさまざまなNode.jsプロジェクトのソースを調べてきましたが、一部の人々が invariant を使用していることに気づきました。私が理解したところによると、invariantは、コードにアサーションを挿入し、必要に応じてエラーを発生させることができるツールです。

質問：

従来の方法でエラーをスローするのではなく、invariantを使用することを好むのはいつですか？

// Using invariant
function doSomething(a, b) {
   invariant(a > b, 'A should be greater than B');
}

// If throw
function doSomething(a, b) {
   if(a <= b) {
      throw new Error('A should be greater than B');
   }
}
javascripterror-handlinginvariants
19
rodrigo-silveira

いくつかの理由があります：

  • それらを積み重ねたいときに読みやすくなります。たとえば、検証する3つの前提条件がある場合、常にinvariant(x ...が表示され、何がチェックされているかを簡単に確認できます。
function f(xs, x) {
    // all the invariants are lined up, one after another
    invariant(xs.type == x.type, "adding an element with the same type");
    invariant(xs.length != LIST_MAX_SIZE, "the list isn't full");
    invariant(fitting(x), "x is fitting right in the list");
}

通常のスローアプローチと比較してください。

function f(xs, x) {
    if (xs.type != x.type)
       throw new Error("adding an element with the same type");
    if (xs.length == LIST_MAX_SIZE)
       throw new Error("the list isn't full");
    if (!fitting(x))
       throw new Error("x is fitting right in the list");
}

  • これにより、リリースビルドで簡単に削除できます。

    多くの場合、dev/testで前提条件をチェックする必要がありますが、リリースが非常に遅いため、前提条件をリリースしたくない場合があります。このようなinvariant関数がある場合は、babel（またはその他）などのツールを使用して、これらの呼び出しを本番ビルドから削除できます（これはDの方法と多少似ています）。

25
Ven