Heim > Backend-Entwicklung > Golang > Warum kann Nested „Defer' Panics in Go nicht wiederherstellen?

Warum kann Nested „Defer' Panics in Go nicht wiederherstellen?

Linda Hamilton
Freigeben: 2024-11-23 10:33:12
Original
508 Leute haben es durchsucht

Why Does Nested `defer` Fail to Recover Panics in Go?

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!")
}
Nach dem Login kopieren

Bei der Ausführung funktioniert dieser Code wie beabsichtigt:

Recovered: OMG!
Nach dem Login kopieren

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!")
}
Nach dem Login kopieren

Das Ergebnis ändert sich:

Recovered: <nil>
panic: OMG!

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

Die Diskrepanz ergibt sich aus dem einzigartigen Verhalten von „recover()“. Gemäß der Go-Spezifikation erholt sich():

  • Gibt Null zurück, wenn:

    • Das Panikargument war Null
    • Die Goroutine ist nicht panicking
    • recover() wurde nicht direkt von einem Deferred aufgerufen Funktion

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!

Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage