Can a Caller Function Recover from a Child Goroutine Panic?

Caller Function Recovery from Child Goroutine Panics

Contrary to popular belief, a goroutine's panic does not necessarily terminate the entire program. This misconception stems from the assumption that deferred recovery functions in the caller will handle the panic. However, this is not the case if the caller finishes before the panic occurs in the goroutine.

Consider the following example:

<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>

Despite the caller function (fun1) finishing execution, the program still terminates if fun2 panics. This occurs because the Go specification defines that when a panic occurs in a goroutine:

• The execution of that goroutine terminates.
• The deferred functions called by that goroutine execute.
• The deferred functions of its caller execute.

In this case, fun2 is the top-level function in the goroutine, and it does not recover from the panic. Therefore, the program terminates.

The key point is that:

A goroutine cannot recover from a panic that occurs in another goroutine.

The above is the detailed content of Can a Caller Function Recover from a Child Goroutine Panic?. For more information, please follow other related articles on the PHP Chinese website!