Considérez le code Golang suivant :
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { defer printRecover() panic("OMG!") }
Ce programme simple panique et récupère avec succès le résultat suivant :
Recovered: OMG!
Cependant, modifier le code pour envelopper printRecover() dans un autre la fonction différée entraîne un résultat différent :
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { defer func() { printRecover() }() panic("OMG!") }
Dans ce cas, la panique n'est pas récupérée, provoquant le crash du programme :
Recovered: <nil> panic: OMG! goroutine 1 [running]: main.main() /tmp/sandbox898315096/main.go:15 +0x60
L'explication de ce comportement réside dans le façon dont recovery() fonctionne dans Golang. Selon la spécification du langage :
The return value of recover is nil if any of the following conditions holds: - panic's argument was nil; - the goroutine is not panicking; - recover was not called directly by a deferred function.
Dans le premier exemple, recovery() est appelé directement par une fonction différée, il récupère donc avec succès l'argument de panique. Dans le deuxième exemple, cependant, recovery() n'est pas appelé directement par une fonction différée, mais plutôt par une fonction elle-même appelée par une fonction différée. En conséquence, recovery() renvoie zéro et la panique n'est pas récupérée.
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!