web-dev-qa-db-ja.com

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

私たち（そして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番目のパターンにあるので、私は反対だと思います。

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

javascripterror-handling
12
Florian Margaine

本当に重要な機能はスタイルの一貫性です。そのため、同じスタイルでコードを記述でき、非同期の状況がどのように処理されるかについてメタプログラミングを想定できます。

個人的には

(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
})

コールバックの最後のアプローチは、Nice APIの親しみやすさのアプローチです。

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

(err, data)毎回このエラーを効率的に処理する方法を考えるように促します。

5
Raynos

一般的に、explicitは常に暗黙よりも優れていることを覚えておきます

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

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

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

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

言うまでもなく、このボイラープレートを追加するのを忘れ、たとえば、成功のみを処理している場合、コードベースを入力する新しい開発者は、問題を確認できない場合があります。しかし、明示的なエラー/成功コールバックがあれば、errorコールバックがないことをすぐに確認し、それを処理する方法に取り掛かるか、少なくとも「これは成功のみを処理する-エラーを処理する方法を見つけなければならない」これにより、コードはそれほど魔法のように見えなくなります。

2
Nathan Hoad

個別のコールバック

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

成功が部分的な成功を表す可能性があることが判明した場合は、それを個別に示します。失敗は通常、救済策です。

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

2
JBRWilkinson