Różne wywołania zwrotne błędu lub błędu jako pierwszy argument?

Kilka dni temu my (i pokój rozmów JS SO) rozmawialiśmy z @rlemon na temat jego biblioteki Little-XHR na temat obsługi błędów.

Zasadniczo chcieliśmy zdecydować, który wzorzec obsługi błędów powinien zostać użyty:

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

Lub:

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

Jeden jest bardziej podobny do jQuery, podczas gdy drugi jest bardziej podobny do węzła. Niektórzy twierdzą, że pierwszy wzorzec sprawia, że ​​myślisz o obsłudze błędów. Myślę, że jest odwrotnie, ponieważ możesz zapomnieć o innej funkcji wywołania zwrotnego, podczas gdy argument zawsze znajduje się na drugim wzorze.

Wszelkie opinie / zalety / wady dotyczące obu tych wzorów?

Prawdziwą ważną cechą jest spójność stylu, dzięki czemu możesz pisać kod w tym samym stylu, a także możesz przyjmować założenia dotyczące programowania meta dotyczące obsługi sytuacji asynchronicznych.

Ja osobiście wolę

(err, data)ponieważ jest to standardowy sposób postępowania. Pozwala na kompozycję funkcji.

Na przykład after.mapużywa tego wzorca. Więc kod jak

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

można uprościć do

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

Kolejną zaletą jest to, że można przekazać wywołanie zwrotne jako ostatni parametr

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

Ostatnie podejście do wywołania zwrotnego jest przyjemnym podejściem do API.

Kolejną zaletą jest to, że można łatwo zapomnieć o ustawieniu modułu errorobsługi w literale obiektu lub ustawieniu go na domyślny moduł obsługi błędów.

Kiedy (err, data)go używasz , przypomina ci, abyś myślał o tym, jak efektywnie radzić sobie z tym błędem za każdym razem.

Ogólnie lubię pamiętać, że jawne jest zawsze lepsze niż dorozumiane.

Korzystając z tego, zwykle opowiadam się za jawnymi successi failurefunkcjami - dokładnie wiesz, z czym masz do czynienia w momencie, gdy otwierasz ten kod - sukces zajmuje wywołania, które zakończyły się sukcesem, podczas gdy błąd zajmuje się wywołaniami, które miały problem.

Alternatywa, przy użyciu jednej metody, zajmie więcej czasu, aby przejść do modyfikacji tego kodu. Poza tym prawdopodobnie skończyłbyś z czymś takim;

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

I ten rodzaj bojlera szybko się nudzi.

Nie wspominając o tym, że jeśli zapomnisz dodać ten szablon, i na przykład radzisz sobie tylko z sukcesem, to nowy programista wprowadzający bazę kodu może nie widzieć problemu z tym. Ale mając wyraźne informacje zwrotne o błędach / sukcesach, dość szybko mogliby zobaczyć, że brakuje ci erroroddzwaniania i zacząć pracować nad sposobem, aby sobie z tym poradzić, lub przynajmniej wymyślić „cóż, to tylko obsługa sukcesu - muszę znaleźć sposób na obsługę błędów ". Sprawia, że ​​kod wydaje się mniej magiczny.

Oddzielne połączenia zwrotne

Jeśli xhr.get()połączenie się powiedzie, to errjest zbędne. Jeśli połączenie się nie powiedzie. datajest zbędny. Zamiast zmuszać kod klienta do sprawdzania stanu jednego lub drugiego, nie należy przekazywać obu.

Jeśli okaże się, że sukces może oznaczać częściowy sukces, zaznacz to osobno. Awaria jest zwykle opcją ratunkową.

Współpracowałem z programistami, którzy zawsze zajmują się przypadkiem sukcesu, aw wielu scenariuszach wystarczy wdrożenie oddzwaniania w tym przypadku. Odwołanie wielostanowe byłoby katastrofalną opcją dla tego stylu programowania, ponieważ zakładałyby sukces.