defer, panic & recover

defer schedules cleanup at function exit, panic starts stack unwinding, and recover can halt that unwind - but only inside a deferred call.

These three mechanisms are Go's answer to structured teardown without exceptions for normal errors.

Summary

defer pushes calls onto a per-goroutine LIFO stack executed when the surrounding function returns.

Arguments to deferred functions are evaluated immediately, but the call waits until return.

panic runs deferred calls while searching for a recover.

recover returns the panic value only during that unwind.

Expected failures should use error returns, not panic.

Recipe

Quick-reference recipe card - copy-paste ready.

package main
 
import (
    "fmt"
    "os"
)
 
func readConfig(path string) (string, error) {
    f, err := os.Open(path)
    if err != nil {
        return "", err
    }
    defer f.Close()
 
    buf := make([]byte, 64)
    n, err := f.Read(buf)
    if err != nil {
        return "", err
    }
    return string(buf[:n]), nil
}
 
func main() {
    text, err := readConfig("config.txt")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(text)
}

When to reach for this:

• Use defer immediately after a successful resource acquisition (Open, Lock, BeginTx).
• Use panic for impossible states that indicate programmer bugs, not I/O failures.
• Use recover at process boundaries (HTTP middleware, worker top-level) to log and return 500.
• Return error for anything a caller could reasonably handle or retry.

Working Example

package main
 
import (
    "fmt"
    "sync"
)
 
func worker(id int, wg *sync.WaitGroup) {
    defer wg.Done()
 
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("worker %d recovered: %v\n", id, r)
        }
    }()
 
    if id == 2 {
        panic("simulated bug")
    }
    fmt.Println("worker", id, "ok")
}
 
func main() {
    var wg sync.WaitGroup
    for id := 1; id <= 3; id++ {
        wg.Add(1)
        go worker(id, &wg)
    }
    wg.Wait()
    fmt.Println("all workers finished")
}

What this demonstrates:

• defer wg.Done() runs even when panic fires later in the function.
• Inner defer with recover catches panic without killing the whole program.
• Other goroutines continue - panic is per-goroutine unless it reaches main.
• Ordering: deferred calls run LIFO before the function truly returns.

Deep Dive

How It Works

• Each goroutine maintains a defer stack; pushing happens at defer statement execution time.
• Deferred function arguments are evaluated at the defer line, not at unwind time (watch loop variables and pointers).
• On panic, the runtime runs deferred functions from innermost outward until recover stops propagation or the stack ends.
• If panic is not recovered, the program prints a stack trace and exits (or kills the goroutine in workers).
• recover() outside a deferred function always returns nil.

defer / panic / recover Timeline

Go Notes

// Named result + defer can adjust return values
func divide(a, b int) (q int, err error) {
    defer func() {
        if b == 0 {
            err = fmt.Errorf("divide by zero")
        }
    }()
    return a / b, nil // careful: division still panics on zero in this naive form
}
 
// Prefer explicit check before division instead of relying on panic

Gotchas

• Defer in loops - for { defer f() } grows the defer stack until the function returns. Fix: wrap loop body in a nested function or defer outside the hot loop.
• Capturing loop variables in defer args - Arguments evaluate once per defer statement; closures in deferred func literals see final values. Fix: pass values as parameters: defer func(v int) { ... }(i).
• Recover outside defer - recover() returns nil and does not stop panic. Fix: only call recover inside defer func() { ... }().
• Swallowing all panics silently - Empty recover hides bugs. Fix: log stack, increment metrics, return 500 to clients.
• Using panic for control flow - Makes APIs hard to use and test. Fix: return error or a (T, bool) result.
• Defer cost in tight loops - Measurable overhead in benchmarks. Fix: hoist defer to outer function or use explicit cleanup when proven hot.

Alternatives

FAQs

Related

• Control Flow in HTTP Middleware - recover at request boundaries
• Control Flow Basics - first defer and recover snippets
• Go Control Flow: Expression-Oriented Design - how defer fits expression-oriented flow
• if with Initialization & switch Patterns - open files then defer close
• Control Flow Best Practices - when not to panic

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).