Gérer les erreurs dans les promesses et avec async/await

Objectif

Chaque promesse rejetée est soit traitée là où une action utile est possible, soit signalée comme un échec journalisé avec son contexte. Aucune n'est abandonnée silencieusement, et aucune ne fait planter le processus par surprise.

Prérequis

Une fonction async renvoie toujours une promesse : un throw à l'intérieur devient un rejet, et await sur une promesse rejetée relance l'exception à cet endroit précis (MDN). Il faut connaître la politique de l'environnement d'exécution pour les rejets que personne ne traite : les navigateurs déclenchent un événement unhandledrejection sur window ; Node.js, avec l'option par défaut --unhandled-rejections=throw, le lève comme une exception non interceptée, ce qui met fin au processus si elle n'est pas gérée.

Étapes

1. Pour chaque appel attendu, décider si l'appelant peut s'en remettre (nouvelle tentative, repli, affichage d'un message). C'est seulement alors qu'on l'encapsule : try { data = await load(); } catch (e) { ... } autour des instructions susceptibles d'échouer, pas autour de toute la fonction.
2. Quand aucun rétablissement n'est possible, laisser le rejet se propager, ou relancer une erreur plus spécifique qui conserve l'originale attachée (new Error("profile load failed", { cause: e })) afin que la pile d'appels survive.
3. Ne jamais laisser une promesse flotter sans suite. Un appel sans await, return ni .catch est un rejet que personne ne prend en charge ; activer une règle de lint qui signale les promesses non attendues et corriger chaque occurrence.
4. Ne pas mélanger des chaînes .then() et await dans une même fonction ; un return manquant à l'intérieur d'un .then cache l'échec au try englobant.
5. Pour un travail concurrent, choisir délibérément : Promise.all lorsqu'un seul échec invalide le lot, Promise.allSettled lorsque des résultats partiels sont utiles. Dans les deux cas, chaque promesse d'entrée reçoit un gestionnaire, afin que des échecs ultérieurs ne deviennent pas non gérés.
6. Enregistrer un gestionnaire de dernier recours qui journalise la raison et l'origine de la promesse : window.addEventListener("unhandledrejection", ...) dans le navigateur, process.on("unhandledRejection", ...) dans Node.js. Dans un processus serveur, journaliser puis arrêter plutôt que de continuer dans un état inconnu.
7. Toujours rejeter avec des instances Error ; une chaîne de caractères rejetée n'a ni pile d'appels ni cause.
8. Écrire un test pour chaque chemin d'échec documenté, qui vérifie le type et le message du rejet.

Résultat attendu

Les échecs apparaissent une seule fois, dans une seule ligne de journal avec son contexte, au niveau qui a décidé de la conduite à tenir. Les exécutions d'intégration continue ne montrent aucun avertissement de rejet non géré.

Limites et base de vérification

Une annulation n'est pas une condition d'erreur ; une AbortError provenant d'un fetch annulé doit être reconnue et ignorée, non signalée. Le comportement décrit suit la documentation citée ; aucune mesure n'est revendiquée.