Il n'y a aucun intérêt à attraper et à lancer un objet nu comme vous le montrez. Il ne fait rien d'utile, sauf ajouter du code et ralentir l'exécution. Donc, si vous voulez .catch()
et rethrow, il devrait y avoir quelque chose que vous voulez faire dans le fichier .catch()
sinon, vous devez simplement supprimer le .catch()
entièrement.
Le point habituel pour cette structure générale est lorsque vous voulez exécuter quelque chose dans la section .catch()
comme enregistrer l'erreur ou nettoyer un état (comme fermer des fichiers), mais vous voulez que la chaîne de promesses continue comme elle a été rejetée.
promise.then(function(result){
//some code
}).catch(function(error) {
// log and rethrow
console.log(error);
throw error;
});
Dans un tutoriel, il peut être là uniquement pour montrer aux gens où ils peuvent attraper les erreurs ou pour enseigner le concept de traitement de l'erreur, puis de rejet.
Voici quelques-unes des raisons utiles pour attraper et relancer :
- Vous voulez enregistrer l'erreur mais conservez la chaîne de promesses telle que rejetée.
- Vous voulez transformer l'erreur en une autre erreur (souvent pour faciliter le traitement des erreurs en fin de chaîne). Dans ce cas, il faut relancer une autre erreur.
- Vous voulez faire un tas de traitement avant que la chaîne de promesse continue (comme les ressources fermées/libres) mais vous voulez que la chaîne de promesses reste rejetée.
- Vous voulez un endroit où placer un point d'arrêt pour le débogueur à ce stade de la chaîne de promesses s'il y a un échec.
- Vous voulez traiter une erreur spécifique ou un ensemble d'erreurs mais renvoie les autres afin qu'ils se propagent à l'appelant.
Mais, un simple catch et rethrow de la même erreur sans autre code dans le catch handler ne fait rien d'utile pour le fonctionnement normal du code.
0 votes
Pourriez-vous fournir un lien vers le tutoriel ? Peut-être y a-t-il un contexte supplémentaire qui serait utile...
0 votes
@Igor Je ne peux pas, c'est sur Pluralsight. C'est peut-être juste un espace pour une logique de gestion des erreurs ?
0 votes
C'est ce que je suppose, car il ne fait rien de plus que de transmettre l'erreur à l'appelant, ce qui pourrait également être accompli en n'ayant pas le catch pour commencer.
1 votes
@TylerDurden Je pense que vous avez raison de dire qu'il s'agit d'un espace réservé.
0 votes
@TylerDurden, je pense aussi que c'est un espace réservé. Peut-être que l'on essaie de démontrer comment formater/normaliser les erreurs. En fait, l'équivalent de la promesse de
try { ... }catch(error){ throw new Error("something went wrong") }
. Ou pour montrer que les Promesses et les Erreurs sont compatibles (du moins dans ce sens) . Mais dans sa mise en œuvre actuelle, c'est juste stupide. Vous avez raison, cela ne fait rien et ce n'est même pas comme un crochet que vous ajouteriez en POO pour permettre de l'écraser dans une classe héritière. J'ajouterais le bloc de capture dès qu'il fait quelque chose, mais pas comme ça, pas seulement comme un substitut.