Warum behandelt eine verzögerte „Wiederherstellung' in einer Aufruferfunktion Paniken in untergeordneten Goroutinen nicht?

Wie Aufruffunktionen mit Panik in untergeordneten Goroutinen umgehen

Früher glaubte man, dass eine Panik in einer Goroutine das Programm beenden würde, wenn seine Aufruffunktion funktioniert fertig, bevor die Panik ausbrach. Ein aktuelles Codebeispiel legt jedoch etwas anderes nahe:

<code class="go">func fun1() {
    fmt.Println("fun1 started")
    defer func() {
        if err := recover(); err != nil {
            fmt.Println("recover in func1")
        }
    }()

    go fun2()

    time.Sleep(10 * time.Second) // wait for the boom!
    fmt.Println("fun1 ended")
}

func fun2() {
    fmt.Println("fun2 started")

    time.Sleep(5 * time.Second)
    panic("fun2 booom!")

    fmt.Println("fun2 ended")
}</code>

Überraschenderweise wird das Programm unabhängig davon beendet, ob die Aufruffunktion (fun1) vor oder nach der Panik in der untergeordneten Goroutine (fun2) beendet wird. Dies wirft die Frage auf: Warum verhindert der verzögerte Wiederherstellungsmechanismus in der Aufruffunktion nicht, dass das Programm abstürzt?

Erläuterung der Spezifikation

Gemäß der Go-Spezifikation:

"Während der Ausführung einer Funktion F beendet ein expliziter Panikaufruf oder eine Laufzeitpanik die Ausführung von F. Alle von F zurückgestellten Funktionen werden dann wie gewohnt ausgeführt. Als nächstes werden alle vom F-Aufrufer ausgeführten zurückgestellten Funktionen ausgeführt usw., bis hin zu allen von der obersten Ebene in der ausführenden Goroutine verzögerten Funktionen. An diesem Punkt wird das Programm beendet und der Fehlerzustand wird gemeldet, einschließlich des Werts des Arguments für Panik. Diese Beendigungssequenz wird als Panik bezeichnet. „

Anwendung auf den Code

Beim Anwenden dieser Spezifikation auf unseren Code beobachten wir Folgendes:

• Wenn fun2 in Panik gerät, wird es zum Goroutine der obersten Ebene und wird beendet.
• Da fun2 sich nicht von der Panik erholt, wird das Programm beendet.
• Der verzögerte Aufruf in fun1 wird nicht aufgerufen, da die Panik in einer anderen Goroutine auftritt.

Fazit

Daher ist es wichtig zu verstehen, dass sich eine Goroutine nicht von einer Panik in einer anderen Goroutine erholen kann. Wenn eine untergeordnete Goroutine in Panik gerät, kann nur die Goroutine selbst die Panik mithilfe des Verzögerungs-/Wiederherstellungsmechanismus bewältigen. Wenn die untergeordnete Goroutine nicht wiederhergestellt wird, wird das gesamte Programm beendet, unabhängig vom Status seines Aufrufers.

Das obige ist der detaillierte Inhalt vonWarum behandelt eine verzögerte „Wiederherstellung' in einer Aufruferfunktion Paniken in untergeordneten Goroutinen nicht?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!