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');
   }
}
19

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

  • それらを積み重ねたいときに読みやすくなります。たとえば、検証する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