Sujet : error-handling
-
Gestion des erreurs PowerShell dans les scripts d'administration : erreurs terminales, $ErrorActionPreference et $LASTEXITCODE
PowerShell distingue deux classes d'erreurs aux comportements différents dans un script : les erreurs terminales, que try/catch permet d'intercepter, et les erreurs non terminales, que seuls $ErrorActionPreference ou -ErrorAction peuvent transformer en arrêt. Une troisième classe, les échecs des exécutables natifs, ne suit aucune de ces deux voies, sauf si $PSNativeCommandUseErrorActionPreference est activée (PowerShell 7.4+, expérimentale en 7.3).
-
Vérifier si un wrapper de tâche a masqué l'échec de sa commande interne
Déterminer si une tâche signalée comme réussie a effectivement propagé le résultat du compilateur, du lanceur de tests ou de la commande de migration dont dépend ce succès.
-
Gestion des erreurs en Go : encapsuler avec %w, errors.Is et errors.As
Les fonctions Go renvoient les erreurs comme des valeurs ordinaires ; ajouter du contexte avec fmt.Errorf et le verbe %w pour que l'erreur d'origine reste accessible, puis tester la chaîne avec errors.Is pour les valeurs sentinelles et errors.As (ou le générique errors.AsType) pour les types, plutôt que de comparer des chaînes ou d'utiliser ==.
-
Gérer les erreurs dans les promesses et avec async/await
Une fonction async transforme un throw en rejet, et await le relance ; chaque rejet a besoin d'un responsable. N'encapsuler que ce dont on peut se remettre, ne jamais laisser une promesse flotter sans suite, utiliser allSettled lorsqu'un échec partiel est acceptable, et enregistrer un gestionnaire unhandledrejection en dernier recours.
-
Tester les chemins d'erreur et les délais d'expiration des appels sortants
Lister les classes de défaillance de chaque dépendance (connexion refusée, réinitialisée, délai de connexion, délai de lecture, 5xx, 429, corps malformé ou lent), injecter chacune avec une doublure de test au niveau unitaire et un proxy injecteur de fautes au niveau intégration, et vérifier le comportement promis : tentatives, backoff, erreurs typées, nettoyage et absence d'écritures partielles.
-
Result, Option et l'opérateur ? : la gestion des erreurs en Rust
Rust ne connaît ni exceptions ni null : les opérations faillibles renvoient Result<T, E>, les valeurs absentes sont représentées par Option<T>, et les deux sont des énumérations que le compilateur oblige à traiter par filtrage (match). L'opérateur ? renvoie Err ou None de façon anticipée et convertit les types d'erreur via From ; un Result ignoré déclenche un avertissement du compilateur, car le type est marqué #[must_use].
Lisible par machine : JSON