Quelle version async utilisez-vous?
v2.5.0
Dans quel environnement le problème s'est-il produit (version du nœud / version du navigateur)
v6.10.3
Qu'est-ce que tu as fait?
async.auto({
returnOne: (callback) => callback(null, 1),
tryCatch: ["returnOne", (results, callback) => {
try {
assert(results.returnOne === 1);
return callback(null);
} catch (err) {
console.log(`Caught an error: ${err.message}`);
return callback(err);
}
}],
}, (err, results) => {
assert(results.returnOne !== 1);
console.log(`All Done!`);
});
Que vous attendiez-vous?
L'assertion à l'intérieur du rappel final aync.auto échoue et renvoie une erreur qui n'est pas interceptée et arrête le processus Node.js. Dans mon exemple réel de cela, nous testons un bloc de code dans Mocha, qui gère l'erreur et signale que le test a échoué avec des informations sur l'assertion qui a causé l'échec.
Quel a été le résultat réel?
Try / Catch de l'étape automatique précédente intercepte l'erreur et appelle le rappel tryCatch une deuxième fois, ce qui entraîne une erreur différente:
async/dist/async.js:903
if (fn === null) throw new Error("Callback was already called.");
^
Error: Callback was already called.
try {
//...
return callback(null, result)
} catch (e) {
//..
return callback(e)
}
C'est un énorme anti-pattern parce que si quelque chose se lance plus tard dans la chaîne de rappel (par exemple votre assertion), il sera pris dans le bloc try
, provoquant un double rappel dans le catch
. Bonne façon:
let err, result
try {
result = doSomething()
} catch (e) {
err = e
}
callback(err, result)
@aearly Cela a du sens, merci pour le tuyau!
(Aussi, bonjour! 👋)
👋😊
Commentaire le plus utile
C'est un énorme anti-pattern parce que si quelque chose se lance plus tard dans la chaîne de rappel (par exemple votre assertion), il sera pris dans le bloc
try
, provoquant un double rappel dans lecatch
. Bonne façon: