Різні зворотні дзвінки про помилку чи помилку як перший аргумент?

Ми (і кімната для спілкування JS SO) поговорили з @rlemon кілька днів тому про його бібліотеку Little-XHR про поводження з помилками.

В основному ми хотіли вирішити, який шаблон обробки помилок слід використовувати:

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

Або:

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

Один більше схожий на jQuery, а інший - більш схожий на Node. Деякі кажуть, що перший зразок змушує задуматися більше про помилку обробки. Я думаю, що навпаки, оскільки ви можете забути іншу функцію зворотного виклику, тоді як аргумент завжди є на другому шаблоні.

Якась думка / перевага / недолік щодо обох цих моделей?

Справжньою важливою особливістю є послідовність стилів, щоб ви могли писати код у тому ж стилі, а також можете робити припущення щодо метапрограмування щодо асинхронних ситуацій.

Я особисто віддаю перевагу

(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.

Наступна перевага полягає в тому, що ви можете легко забути встановити 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є зайвим. Замість того, щоб примушувати клієнтський код перевіряти стан того чи іншого, не передайте обидва.

Якщо виявиться, що успіх може представляти частковий успіх, зазначте це окремо. Збій - це зазвичай варіант відшкодування.

Я працював з розробниками, які тільки коли-небудь обробляють справу успіху, і в багатьох сценаріях просто реалізація зворотного виклику успіху буде в цьому випадку достатньо. Багатодержавний зворотний виклик був би катастрофічним варіантом для цього стилю програмування, оскільки вони мали б успіх.