最初の引数としてエラーまたはエラーの異なるコールバック？

私たち（およびJS SOチャットルーム）は、エラー処理に関する彼のLittle-XHRライブラリについて、数日前に@rlemonと話しました。

基本的に、どのエラー処理パターンを使用するかを決定したかったのです。

xhr.get({
    // Some parameters, and then
    success: function(data) {},
    failure: function(data) {}
})

または：

xhr.get({
    // Some parameters, and then
    callback: function(err, data) {}
})

1つはjQueryに似ていますが、もう1つはノードに似ています。最初のパターンは、エラーの処理についてもっと考えるようになると言う人もいます。あなたは他のコールバック関数を忘れるかもしれないので、私は反対だと思いますが、引数は常に2番目のパターンにあります。

これらの両方のパターンに関する意見/利点/欠点はありますか？

本当に重要な機能はスタイルの一貫性であるため、同じスタイルでコードを記述でき、非同期の状況の処理方法についてメタプログラミングの前提を立てることができます。

私は個人的に好む

(err, data)それは物事を処理する標準的な方法だからです。関数の合成が可能です。

たとえば、after.mapこのパターンを使用します。だからコードのような

after.map(["foo.js", "bar.js"], function (fileName, callback) {
    fs.readFile(fileName, function (err, file) {
        callback(err, file)
    })
}, function (err, files) {
    // handle files
})

に簡略化することができます

after.map(["foo.js", "bar.js", fs.readFile, function (err, files) {
    // handle files
})

別の利点は、最後のパラメーターとしてコールバックを渡すことができることです

asyncOperation(options, function (err, data) {
    // not nested inside an object literal
})

最後のコールバックアプローチは、APIに馴染みのあるアプローチです。

もう1つの利点はerror、オブジェクトリテラルでハンドラーを設定することを忘れたり、何らかの種類のデフォルトエラーハンドラーに設定することを簡単に忘れることができることです。

使用(err, data)するときは、このエラーを毎回効率的に処理する方法を考えるように思い出させます。

一般に、明示的は暗黙的よりも常に優れていることを覚えておきたいです。

これを使用して、通常、明示的な関数successとfailure関数を使います-そのコードを開いた瞬間に何を扱っているかを正確に知っています-成功は正常に終了した呼び出しを処理し、エラーは問題のある呼び出しを処理します。

単一の方法を使用する別の方法では、そのコードを変更するときに読むのに時間がかかります。その上、おそらくこのようなものになるでしょう。

xhr.get({
    callback: function(err, data) {
        if (err) {
            // handle that error somehow
        }
        else {
            // deal with success somehow
        }
    }
})

そして、その種の定型文は退屈で、速くなります。

言うまでもなく、この定型文を追加するのを忘れて、たとえば、成功のみを処理している場合、コードベースを入力する新しい開発者は、それに関する問題を見ることができません。しかし、明示的なエラー/成功コールバックを持っていると、errorコールバックが欠落していることがすぐにわかり、それを処理する方法で作業を開始するか、少なくとも「これは成功を処理するだけです-私はする必要がありますエラーを処理する方法を見つけてください」。コードの魔法のように見えます。

個別のコールバック

場合はxhr.get()呼び出しが成功した場合、err冗長です。呼び出しが失敗した場合。data冗長です。クライアントコードにどちらか一方の状態を強制的にチェックさせるのではなく、両方を渡さないでください。

成功が部分的な成功を表すことが判明した場合は、それを個別に示します。通常、失敗は救済オプションです。

私は、成功事例のみを扱う開発者と協力してきましたが、多くのシナリオでは、この場合は成功コールバックを実装するだけで十分です。マルチステートコールバックは、成功を前提とするため、そのスタイルのプログラミングにとって壊滅的なオプションになります。