La fonction recover() en Go ne stoppe une panique que si elle est appelée directement dans une fonction différée qui s'exécute dans le cadre du processus de retour en arrière provoqué par cette panique. Lorsque vous invoquez recover() à l'intérieur d'une fonction d'aide qui a elle-même été invoquée par une fermeture différée, le runtime détecte que le cadre d'exécution actuel de la goroutine n'est pas le cadre différé de premier niveau associé à la panique active.
// Ce modèle ÉCHOUE à récupérer : func handlePanic() { if r := recover(); r != nil { log.Println("Récupéré :", r) } } func risky() { defer handlePanic() // recover() retourne nil ici panic("erreur") }
Le runtime maintient cette vérification à travers le champ g.recover, qui stocke le pointeur du cadre de pile de la fonction différée qui a l'autorité de récupérer. Lorsque recover() s'exécute, il compare le pointeur de pile actuel contre cette valeur stockée ; s'ils ne correspondent pas, recover() retourne nil et la panique continue de se propager dans la pile. Cette contrainte architecturale garantit que la logique de récupération reste explicite et localisée, empêchant les fonctions d'aide profondément imbriquées d'avaler accidentellement des paniques qui devraient remonter à des gestionnaires de récupération de niveau supérieur.
Dans un microservice à fort débit gérant des milliers de goroutines concurrentes, nous avons mis en œuvre un mécanisme centralisé de récupération de panique pour éviter les plantages de serveur dus à des requêtes mal formées. La mise en œuvre initiale utilisait une fonction utilitaire SafeRecover() qui encapsulait la journalisation et les métriques, et les développeurs différaient cette fonction au début de chaque gestionnaire en utilisant defer SafeRecover(). Cependant, lors d'un incident de production impliquant une erreur de division par zéro dans un gestionnaire de requêtes, le service a planté malgré le mécanisme de récupération apparent, indiquant que la panique n'était pas interceptée parce que recover() était imbriqué dans l'aide plutôt qu'appelé directement.
Nous avons d'abord envisagé d'exiger que les développeurs écrivent manuellement defer func() { if r := recover(); r != nil { ... } }() à chaque point d'entrée de fonction. Cette approche offrait un accès direct à recover(), garantissant la conformité d'exécution, mais introduisait un bruit de base significatif et reposait sur la cohérence humaine, ce qui rendait cela susceptible d'erreurs pour une grande équipe et difficile à appliquer lors des revues de code.
La deuxième approche impliquait de modifier SafeRecover() pour accepter une fermeture comme argument et exécuter recover() dans cette fonction passée avant d'invoquer la logique d'aide. Bien que cela satisfasse techniquement l'exigence en plaçant recover() dans le cadre différé, cela créait une API maladroite où les gestionnaires devaient passer leur logique de récupération sous forme de rappels, compliquant le flux de contrôle et réduisant la lisibilité tout en ajoutant une indirection inutile.
Nous avons finalement sélectionné la troisième approche : la mise en œuvre d'un wrapper middleware au niveau du routeur HTTP qui exécutait defer func() { if r := recover(); r != nil { logAndMetrics(r) } }() directement au sein de la fermeture différée du middleware. Cette solution a garanti que recover() était invoqué à la profondeur de pile correcte tout en maintenant une séparation claire des préoccupations, résultant en un taux d'interception des paniques de 100% lors des tests de chaos ultérieurs et aucune boucle de plantage lors du trimestre suivant.
Pourquoi recover() retourne-t-il nil lorsqu'il est appelé en dehors d'une fonction différée, même lorsqu'aucune panique n'est active ?
En dehors d'un contexte d'exécution différée, recover() interroge l'état de panique de la goroutine actuelle et ne trouve aucun enregistrement de panique actif, ce qui lui fait retourner nil immédiatement. La subtilité est que recover() vérifie si la fonction actuelle s'exécute dans le cadre d'un désenroulement de pile différé, pas simplement si une panique existe quelque part dans le programme. Lorsqu'il est appelé depuis des chemins d'exécution normaux, le runtime découvre que le champ _panic sur la structure de la goroutine est nil et retourne nil sans effets secondaires, empêchant une mauvaise utilisation accidentelle où la gestion des erreurs normales pourrait déclencher des mécanismes de récupération.
Que se passe-t-il lorsque plusieurs fonctions différées dans la même goroutine appellent recover(), et pourquoi seule la première réussit-elle ?
Lorsqu'une panique se produit, Go exécute les fonctions différées dans l'ordre LIFO, et la première fonction différée qui appelle recover() efface atomiquement l'état de panique actif de la liste chaînée interne _panic de la goroutine. Les fonctions différées suivantes qui invoquent recover() constatent que la panique a déjà été résolue, ce qui leur fait recevoir nil au lieu de la valeur de panique d'origine. Ce design garantit une gestion de panique déterministe où le champ de récupération le plus intérieur prend la priorité, et empêche les tentatives de récupération redondantes qui pourraient embrouiller la logique de propagation d'erreur une fois que la pile reprend une exécution normale.
Comment panic(nil) se comporte-t-il différemment de panic("nil") ou panic(0), et pourquoi Go 1.21 a-t-il changé ce comportement ?
Avant Go 1.21, appeler panic(nil) faisait que le runtime traitait la valeur de panique comme un sentinelle spéciale que recover() retournerait comme nil, la rendant indistincte d'un appel à recover() qui n'a trouvé aucune panique à gérer et créant une ambiguïté dangereuse. Dans Go 1.21 et après, le runtime convertit automatiquement une valeur de panique nil en une erreur d'exécution non nulle contenant la chaîne "runtime error: panic called with nil argument", garantissant que recover() retourne toujours une valeur non nulle lorsqu'elle intercepte avec succès une panique. Ce changement a éliminé l'ambiguïté dans le code de gestion des erreurs, permettant aux développeurs de vérifier en toute confiance if r := recover(); r != nil sachant qu'un nil retourné indique réellement qu'aucune panique ne s'est produite.