Warum funktioniert „recover()' nicht in verschachtelten verzögerten Funktionen in Go?

Warum Recover() in verschachtelten verzögerten Funktionen fehlschlägt

Bedenken Sie den folgenden Golang-Code:

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    defer printRecover()

    panic("OMG!")
}

Dieses einfache Programm gerät erfolgreich in Panik und stellt sich mit wieder her die folgende Ausgabe:

Recovered: OMG!

Allerdings wird der Code so geändert, dass printRecover() in einen anderen eingeschlossen wird Die verzögerte Funktion führt zu einem anderen Ergebnis:

package main

import "fmt"

func printRecover() {
    r := recover()
    fmt.Println("Recovered:", r)
}

func main() {
    defer func() {
        printRecover()
    }()

    panic("OMG!")
}

In diesem Fall wird die Panik nicht wiederhergestellt, was zum Absturz des Programms führt:

Recovered: <nil>
panic: OMG!

goroutine 1 [running]:
main.main()
    /tmp/sandbox898315096/main.go:15 +0x60

Die Erklärung für dieses Verhalten liegt in der So funktioniert „recover()“ in Golang. Gemäß der Sprachspezifikation:

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.

Im ersten Beispiel wird „recover()“ direkt von einer verzögerten Funktion aufgerufen, sodass das Panic-Argument erfolgreich abgerufen wird. Im zweiten Beispiel wird „recover()“ jedoch nicht direkt von einer verzögerten Funktion aufgerufen, sondern von einer Funktion, die selbst von einer verzögerten Funktion aufgerufen wurde. Infolgedessen gibt „recover()“ Null zurück und die Panik wird nicht wiederhergestellt.

Das obige ist der detaillierte Inhalt vonWarum funktioniert „recover()' nicht in verschachtelten verzögerten Funktionen in Go?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!