Dévoilement des raisons derrière la récupération inefficace dans les fonctions différées imbriquées
Dans Golang, recovery() sert de mécanisme crucial pour gérer les exceptions et empêcher la propagation des paniques. Cependant, une observation intrigante se produit lors de l’utilisation de recovery() dans des fonctions différées imbriquées. Contrairement aux attentes, des paniques peuvent encore survenir malgré la présence de reports imbriqués.
Pour illustrer cette anomalie, considérons le code suivant :
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Direct deferred call to recover() defer printRecover() panic("OMG!") }
Une fois exécuté, ce code fonctionne comme prévu :
Recovered: OMG!
Cependant, lorsque nous enfermons printRecover() dans un fichier différé imbriqué function :
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Nested deferred call to recover() defer func() { printRecover() }() panic("OMG!") }
Le résultat change :
Recovered: <nil> panic: OMG! goroutine 1 [running]: main.main() /tmp/sandbox898315096/main.go:15 +0x60
L'écart provient du comportement unique de recovery(). Conformément à la spécification Go, recovery() :
Renvoie nul si :
Dans le cas différé imbriqué, recovery() n'a pas été invoqué directement par la fonction différée la plus externe mais par celle imbriquée. Par conséquent, il renvoie zéro, laissant la panique non gérée.
Cette distinction cruciale souligne l'importance d'utiliser recovery() directement dans les fonctions différées pour assurer une récupération de panique efficace dans Golang.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!