3

Nodeでエラーをスローすることは悪い習慣であり、CommonJSのコールバック構文を介して手動でエラーを処理する必要があると多くの人から聞いています。

somethingThatPassesAnError( function(err, value) {
    if (err) console.log("ERROR: " + err);
});

それでも、複数の単体テストフレームワーク（Mocha、Should.js、Gently）で、何かが起こったときにエラーが発生するように思われることがわかりました。throwつまり、確かに、変数の同等性をチェックし、エラー変数でnull以外をチェックするようにテストを設計できますが、Ryan Dahl自身の言葉では、「正しいことを簡単に実行できるようにフレームワークを作成する必要があります。間違ったことをするのは難しい」

では、何が得られるのでしょうか？その慣習が存在する理由を誰かが説明できますか？require()モジュールが見つからなかった場合のように、致命的な例外をスローし始める必要がありますか？

4

4 に答える 4

3

これは、nodejs プログラムは通常 async を多用し、その結果、try/catch が正常に完了した後にエラーがスローされることが多いためです。この不自然な例を考えてみましょう。

function foo(callback) {
  process.nextTick(function() {
    if (something) throw "error";
    callback("data");
  });
}

try {
  foo(function(data) {
    dosomething(data);
  });
} catch (e) {
  // "error" will not be caught here, as this code will have been executed
  // before the callback returns.
}

コールバックの最初の引数がエラーである典型的なノード パターンは、この問題を回避し、非同期コードからエラーを返す一貫した方法を提供します。

function foo(callback) {
  process.nextTick(function() {
    if (something) return callback("error");
    callback("data");
  });
}

foo(function(error, data) {
  if (error) return handleError(error);
  dosomething(data);
});
于 2013-01-19T04:09:03.873 に答える
2

JavaScriptで例外をスローすることに反対するのは、非同期パターンを多用しているためだと私は理解しています。別のスタックでエラーが発生した場合、それをキャッチすることはできません。そのような場合は、このerrパラメーターをコールバックの最初のパラメーターとして使用します。

それは「何も投げない」と同じではないと思います。同期コードがあり、例外が発生した場合は、それをスローします。意見はさまざまですが、コールバックがまったく関与していなければ、使用しない理由はありませんthrow。

于 2013-01-19T04:05:23.813 に答える
0

require（）が機能するのと同じように、例外を使用して重大なエラーを処理することをお勧めします。この機能によってNode.jsが誤動作する場合、それはバグであり、そのうち修正されると確信しています。

于 2013-01-19T04:05:59.887 に答える