2012-06-13 16 views
5

Los programadores parecen estar divididos sobre cómo recibir notificaciones asincrónicas sobre un error.¿Cuáles son las ventajas de usar un errback?

Algunos programadores prefieren utilizar una devolución de llamada con dos argumentos: un valor y un booleano que indica si el valor no es erróneo. Esto tiene la ventaja de que se vea como una declaración try catch:

asyncFunct(function (value, noError) { 
    if (noError) { 
     // success, do something with value 
    } else { 
     // value is the error which is thrown 
    } 
}); 

Otros prefieren el negativo (es decir, el booleano debe decir si el valor es errónea). Su razonamiento es que si se sabe que la función asíncrona no generará un error a continuación, se puede omitir con seguridad el segundo parámetro de la siguiente manera:

asyncFunction(function (value, isErroneous) { 
    if (!isErrorneous) { 
     // success, do something with value 
    } else { 
     // value is the error which is thrown 
    } 
}); 

asyncFunction(function (value) { 
    // success, do something with value 
}); 

luego hay gente que proponen las devoluciones de llamada por separado para la ejecución exitosa de las funciones asíncronas y errbacks para la ejecución errónea de funciones asíncronas. Esto permite al programador seleccionar si quiere manejar las devoluciones de llamada, errbacks, ambos o ninguno:

asyncFunction(function (value) { 
    // success, do something with value 
}, function (error) { 
    // handle the error 
}); 

asyncFunction(function (value) { 
    // success, do something with value 
}); 

asyncFunction(null, function (error) { 
    // handle the error 
}); 

No estoy pidiendo el método que prefiera. Simplemente estoy preguntando las ventajas y desventajas de cada método para saber cuál usar cuando.

+1

No hay ventajas/desventajas reales. Es solo una cuestión de estilo, yo. – freakish

+3

Hay otra manera, que es mucho más poderosa IMO: [objetos diferidos] (http://blogs.msdn.com/b/ie/archive/2011/09/11/asynchronous-programming-in-javascript-with- promises.aspx). –

+1

Prefiero los objetos diferidos también. Pero sea cual sea el método que elija, utilícelo de manera consistente en toda la aplicación, la coherencia suele ser más importante que elegir el mejor enfoque. – msanders

Respuesta

1

Diseño Decisión:

Esto es sólo el diseño de decisiones, nada más. Si se trata de un parámetro independiente, puede tener una función independiente y crear un código "más bello" (para alguien, para alguien es más desordenado, es realmente subjetivo).

error complejidad:

En algunas aplicaciones que puede tener errores más complejos (filesystem.fileRead puede tener FILE_DONT_EXISTS, FILE_LOCKED, NOT_PERMISSIONS ..) y en algunas aplicaciones que necesitan acaba de tirar de error (o db.checkConnectiondb.openConnection).

Orden y diferencias:

muy agradable para la gran muestra de API es de Amazon, se puede comprobar. http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html

RESPUESTA: En asynch función como copyObject(params = {}, callback) que tiene la función de devolución de llamada, que tienen siempre 2 parámetros: err (Error) y data (Object) en function(err, data) { ... }. El error está diseñado como un primer parámetro porque si tiene un error, no tiene datos. Entonces, realmente se trata de prioridad y de orden.

// request 

getObject({ 
    param1 : something, 
    param2 : something, 
    param3 : something 
}, callback); 

// response 

function callback(error, response){ 
    if error throw err; 
    // now deal with responsei 
} 

Como se puede ver, que tienen ambos dos formas mixtas. En la solicitud pasas el objeto y la función y en respuesta obtienes el error y el objeto (a esa función de solicitud).

Cuestiones relacionadas