Diferentes devoluciones de llamada para error o error como primer argumento?

Nosotros (y la sala de chat JS SO) tuvimos una conversación con @rlemon hace unos días sobre su biblioteca Little-XHR sobre el manejo de errores.

Básicamente, queríamos decidir qué patrón de manejo de errores debería usarse:

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

O:

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

Uno es más parecido a jQuery, mientras que el otro es más parecido a Node. Algunos dicen que el primer patrón te hace pensar más sobre el manejo de errores. Creo lo contrario, ya que puede olvidar la otra función de devolución de llamada, mientras que el argumento siempre está ahí en el segundo patrón.

¿Alguna opinión / ventaja / inconveniente sobre estos dos patrones?

La característica realmente importante es la consistencia del estilo, por lo que puede escribir código en el mismo estilo y puede hacer suposiciones de meta programación sobre cómo se manejan las situaciones asincrónicas.

Yo personalmente prefiero

(err, data)porque es una forma estándar de manejar las cosas. Permite la composición de funciones.

Por ejemplo after.mapusa este patrón. Entonces código como

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

se puede simplificar a

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

Otra ventaja es que puede pasar una devolución de llamada como último parámetro

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

El último enfoque de devolución de llamada es un buen enfoque de familiaridad con la API.

Una ventaja adicional es que puede olvidarse fácilmente de configurar el errorcontrolador en su objeto literal, o establecerlo en algún tipo de controlador de error predeterminado.

Cuando lo usa, (err, data)le recuerda que debe pensar cómo manejar este error de manera eficiente cada vez.

En general, me gusta recordar que explícito siempre es mejor que implícito.

Al usar esto, normalmente me pongo del lado de las funciones successy explícitas failure, ya sabes exactamente a qué te enfrentas en el momento en que abres ese código, el éxito trata las llamadas que terminaron con éxito, mientras que el error trata las llamadas que tuvieron un problema.

La alternativa, usando un método único, tomará más tiempo para leer cuando vaya a modificar ese código. Además, es probable que termines con algo como esto;

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

Y ese tipo de repeticiones se vuelve aburrido, rápido.

Sin mencionar que si olvida agregar esta plantilla repetitiva y, por ejemplo, solo está manejando el éxito, entonces un nuevo desarrollador que ingrese a la base del código puede no ver un problema. Pero teniendo devoluciones de llamada explícitas de error / éxito, podrían ver con bastante rapidez que se está perdiendo una errordevolución de llamada y comenzar a trabajar en una forma de manejarlo, o al menos descubrir "bueno, esto solo es manejar el éxito, debo encontrar una manera de manejar los errores ". Hace que el código parezca menos mágico.

Devoluciones de llamada separadas

Si la xhr.get()llamada tiene éxito, entonces erres redundante. Si la llamada falla. dataes redundante En lugar de forzar el código del cliente para verificar el estado de uno u otro, no pase ambos.

Si resulta que el éxito podría representar un éxito parcial, indíquelo por separado. El fracaso suele ser la opción de rescate.

He trabajado con desarrolladores que solo manejan el caso de éxito y en muchos escenarios solo sería suficiente implementar una devolución de llamada de éxito en este caso. Una devolución de llamada multiestatal sería una opción catastrófica para ese estilo de programación, ya que asumirían el éxito.