Gestion des erreurs en Go : encapsuler avec %w, errors.Is et errors.As

Ce que c'est

En Go, une erreur est toute valeur dont le type possède une méthode Error() string ; les fonctions la renvoient comme dernier résultat et nil signifie succès. Il n'y a pas d'exceptions : la FAQ Go explique cette conception comme des retours à plusieurs valeurs pour les échecs ordinaires, plus panic/recover pour les conditions véritablement exceptionnelles. Depuis Go 1.13, les erreurs forment une chaîne. fmt.Errorf("open config: %w", err) renvoie une erreur qui implémente Unwrap() error, et la documentation du paquet errors décrit comment errors.Is et errors.As parcourent cet arbre (une erreur d'abord, puis ses enfants, en profondeur) : Is compare à une valeur cible, As trouve la première erreur assignable à un type cible et la copie. errors.Join (Go 1.20) et fmt.Errorf avec plusieurs verbes %w produisent des erreurs dont Unwrap renvoie []error. Go 1.26 ajoute le générique errors.AsType[E](err), qui renvoie la valeur typée et un booléen.

Pourquoi c'est important

En venant de Python ou de JavaScript, le réflexe est un try/except autour d'un bloc ; en Go, chaque point d'appel décide. Deux habitudes issues des langages dynamiques posent problème ici : comparer des chaînes err.Error(), qui changent dès qu'une couche ajoute du contexte, et comparer err == ErrNotFound avec ==, ce qui échoue dès que l'erreur a été encapsulée. La documentation indique que errors.Is(err, fs.ErrExist) est préférable à err == fs.ErrExist précisément pour cette raison.

Comment l'appliquer

• Déclarer les erreurs sentinelles comme des variables de paquet (var ErrNotFound = errors.New("not found")) et les erreurs structurées comme des types avec des champs ; les appelants font correspondre avec errors.Is ou errors.As.
• Encapsuler avec %w lorsque l'appelant peut raisonnablement inspecter la cause, et avec %v lorsque la cause est un détail d'implémentation ; la recommandation du blog Go est d'encapsuler une erreur pour l'exposer aux appelants, et de ne pas l'encapsuler lorsque cela exposerait des détails d'implémentation.
• Ajouter du contexte une fois par couche sous la forme "what was being done: %w", en minuscules et sans ponctuation finale, afin que les messages se lisent comme une chaîne de l'extérieur vers l'intérieur.
• Traiter ou renvoyer, pas les deux : journaliser une erreur tout en la renvoyant produit des lignes de journal dupliquées à chaque niveau.
• Donner à un type personnalisé une méthode Is(error) bool lorsqu'il doit être considéré égal à une sentinelle existante ; la documentation du paquet décrit ce mécanisme.

Pièges

%v rompt silencieusement la chaîne. Encapsuler une erreur nil crée une erreur non nil. Une fonction qui renvoie un pointeur typé nil comme error renvoie une interface non nil (voir l'article sur les interfaces). Renvoyer sql.ErrNoRows via %w depuis un dépôt lie les appelants au paquet de base de données, ce qui est l'exemple même du blog. panic n'est pas un mécanisme d'erreur général ; le réserver aux erreurs de programmation et ne récupérer qu'aux frontières des goroutines.