recover must be used inside a deferred function to catch a panic and regain control of a goroutine. 2. recover only works during a panic and returns nil otherwise, making it ineffective outside deferred functions. 3. A common use case is protecting API boundaries, such as in HTTP handlers, where a panic is converted into a 500 error response to keep the server running. 4. Panic and recover are not substitutes for normal error handling; errors should be returned normally, and panic reserved for unrecoverable conditions. 5. Each goroutine must have its own deferred recover function, as panics are isolated to their goroutine and will crash it if not locally recovered. In summary, panic and recover act as a safety net for exceptional cases but should be used sparingly and only at critical boundaries to prevent program termination.

Handling panics in Go is done using the recover function, which allows you to regain control of a goroutine that has panicked. Since Go doesn't have exceptions like other languages, panic and recover serve as a last-resort mechanism for handling critical errors — but they should be used sparingly and with care.

Here’s how it works in practice:

1. Use defer with recover to catch a panic

recover only works inside a deferred function. When a panic occurs, the deferred functions run during the stack unwinding, and recover can intercept the panic value.

func safeDivide(a, b int) (result int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic occurred: %v", r)
        }
    }()

    if b == 0 {
        panic("division by zero")
    }
    return a / b, nil
}

In this example, if b is zero, the function panics — but the deferred anonymous function catches it using recover, converts it into an error, and prevents the program from crashing.

2. Recover only makes sense in deferred functions

recover returns nil if it's not called from within a deferred function, or if the goroutine is not panicking. So it's useless outside of a defer.

func badExample() {
    if r := recover(); r != nil { // This will always be nil
        log.Println("Won't catch anything here")
    }
}

Always use recover inside defer:

defer func() {
    if r := recover(); r != nil {
        log.Printf("Recovered from panic: %v", r)
    }
}()

3. Common use case: Protecting API boundaries

A typical scenario is in servers or libraries where you want to prevent a single panic from taking down the whole service — especially in HTTP handlers or goroutines.

func handleRequest(w http.ResponseWriter, r *http.Request) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Panic in handler: %v", r)
            http.Error(w, "Internal Server Error", 500)
        }
    }()

    // ... potentially panicking logic
}

This ensures that even if something unexpected panics (e.g., a nil dereference), the server continues running.

4. Don’t use panic/recover for normal error handling

Go’s idiomatic way to handle expected errors is to return them:

? Do this:

if err != nil {
    return err
}

? Don’t do this:

if err != nil {
    panic(err)
}

Use panic only for truly exceptional conditions — like invariant violations or configuration errors that make the program unsalvageable.

And only use recover when you must contain a panic (e.g., in a library, or to keep a server alive).

5. Recovering in goroutines requires local defer

Each goroutine needs its own defer/recover, because a panic in one goroutine doesn’t affect others — but it will crash that goroutine unless recovered locally.

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Println("Goroutine recovered:", r)
        }
    }()
    panic("oops")
}()

Without the defer in the same goroutine, the panic would go uncaught and could go unnoticed (or cause issues if not logged).

Basically, panic and recover are like safety nets — useful in specific cases, but not a replacement for proper error handling. Use recover defensively at boundaries, and avoid panicking in libraries unless the error is truly unrecoverable.

The above is the detailed content of How do you handle panics in Go?. For more information, please follow other related articles on the PHP Chinese website!