Enthüllung der Gründe für eine ineffektive Wiederherstellung in verschachtelten verzögerten Funktionen
In Golang dient „recover()“ als entscheidender Mechanismus zur Behandlung von Ausnahmen und zur Vorbeugung die Ausbreitung von Panik. Bei der Verwendung von „recover()“ innerhalb verschachtelter verzögerter Funktionen ergibt sich jedoch eine interessante Beobachtung. Entgegen den Erwartungen kann es trotz verschachtelter Verzögerungen immer noch zu Paniken kommen.
Um diese Anomalie zu veranschaulichen, betrachten Sie den folgenden Code:
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Direct deferred call to recover() defer printRecover() panic("OMG!") }
Bei der Ausführung funktioniert dieser Code wie beabsichtigt:
Recovered: OMG!
Wenn wir jedoch printRecover() in ein verschachteltes Deferred einschließen Funktion:
package main import "fmt" func printRecover() { r := recover() fmt.Println("Recovered:", r) } func main() { // Nested deferred call to recover() defer func() { printRecover() }() panic("OMG!") }
Das Ergebnis ändert sich:
Recovered: <nil> panic: OMG! goroutine 1 [running]: main.main() /tmp/sandbox898315096/main.go:15 +0x60
Die Diskrepanz ergibt sich aus dem einzigartigen Verhalten von „recover()“. Gemäß der Go-Spezifikation erholt sich():
Gibt Null zurück, wenn:
Im verschachtelten verzögerten Fall wurde „recover()“ nicht direkt von der äußersten verzögerten Funktion aufgerufen, sondern von der verschachtelten. Folglich gibt es Null zurück, sodass die Panik nicht behandelt wird.
Diese entscheidende Unterscheidung unterstreicht die Bedeutung der Verwendung von „recover()“ direkt innerhalb verzögerter Funktionen, um eine effektive Panikwiederherstellung in Golang sicherzustellen.
Das obige ist der detaillierte Inhalt vonWarum kann Nested „Defer' Panics in Go nicht wiederherstellen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!