defer, panic & recover

defer programa la limpieza al salir de una función, panic inicia el desenrollado de la pila y recover puede detener ese desenrollado, pero solo dentro de una llamada diferida.

Estos tres mecanismos son la respuesta de Go a la limpieza estructurada sin excepciones para errores normales.

Resumen

defer introduce llamadas en una pila LIFO por goroutine que se ejecuta cuando la función circundante retorna.

Los argumentos de las funciones diferidas se evalúan inmediatamente, pero la llamada espera hasta el retorno.

panic ejecuta las llamadas diferidas mientras busca un recover.

recover retorna el valor del panic solo durante ese desenrollado.

Los fallos esperados deben usar retornos error, no panic.

Receta

Tarjeta de receta de referencia rápida, lista para copiar y pegar.

package main
 
import (
    "fmt"
    "os"
)
 
func readConfig(path string) (string, error) {
    f, err := os.Open(path)
    if err != nil {
        return "", err
    }
    // Programa el cierre del archivo para que se ejecute cuando la función retorne
    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)
}

Cuándo usar esto:

• Usa defer inmediatamente después de la adquisición exitosa de un recurso (Open, Lock, BeginTx).
• Usa panic para estados imposibles que indiquen errores de programación, no fallos de I/O.
• Usa recover en los límites del proceso (middleware HTTP, nivel superior de un worker) para registrar y retornar 500.
• Retorna error para cualquier cosa que un llamador pueda manejar o reintentar razonablemente.

Ejemplo Funcional

package main
 
import (
    "fmt"
    "sync"
)
 
func worker(id int, wg *sync.WaitGroup) {
    // Asegura que wg.Done() se llame al final, incluso si ocurre un panic
    defer wg.Done()
 
    // Programa una función para recuperar cualquier panic
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("worker %d recuperado: %v\n", id, r)
        }
    }()
 
    // Simula un error en el worker 2
    if id == 2 {
        panic("error simulado")
    }
    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("todos los workers terminaron")
}

Lo que esto demuestra:

• defer wg.Done() se ejecuta incluso si panic ocurre más tarde en la función.
• El defer interno con recover captura el panic sin terminar todo el programa.
• Otras goroutines continúan; el panic es por goroutine a menos que llegue a main.
• Orden: las llamadas diferidas se ejecutan en LIFO antes de que la función retorne verdaderamente.

Profundización

Cómo Funciona

• Cada goroutine mantiene una pila de defer; la inserción ocurre en el momento de la ejecución de la declaración defer.
• Los argumentos de las funciones diferidas se evalúan en la línea defer, no en el momento del desenrollado (cuidado con las variables de bucle y los punteros).
• En caso de panic, el runtime ejecuta las funciones diferidas de adentro hacia afuera hasta que recover detiene la propagación o la pila termina.
• Si el panic no se recupera, el programa imprime un rastreo de pila y sale (o mata la goroutine en los workers).
• recover() fuera de una función diferida siempre retorna nil.

Cronología de defer / panic / recover

Notas de Go

// Un resultado con nombre + defer puede ajustar los valores de retorno
func divide(a, b int) (q int, err error) {
    defer func() {
        if b == 0 {
            err = fmt.Errorf("división por cero")
        }
    }()
    // Cuidado: la división aún causa panic por cero en esta forma ingenua
    return a / b, nil
}
 
// Prefiere una comprobación explícita antes de la división en lugar de depender del panic

Trampas

• Defer en bucles - for { defer f() } hace crecer la pila de defer hasta que la función retorna. Solución: envuelve el cuerpo del bucle en una función anidada o usa defer fuera del bucle principal.
• Capturar variables de bucle en argumentos de defer - Los argumentos se evalúan una vez por declaración defer; las clausuras en literales de función diferida ven los valores finales. Solución: pasa los valores como parámetros: defer func(v int) { ... }(i).
• Recover fuera de defer - recover() retorna nil y no detiene el panic. Solución: llama a recover solo dentro de defer func() { ... }().
• Ignorar todos los panics silenciosamente - Un recover vacío oculta errores. Solución: registra la pila, incrementa métricas, retorna 500 a los clientes.
• Usar panic para el flujo de control - Hace que las APIs sean difíciles de usar y probar. Solución: retorna error o un resultado (T, bool).
• Costo de defer en bucles ajustados - Costo medible en benchmarks. Solución: eleva defer a la función externa o usa limpieza explícita cuando se demuestre que es un cuello de botella.

Alternativas

Preguntas Frecuentes

Relacionados

• Control Flow in HTTP Middleware - recover en los límites de la solicitud
• Control Flow Basics - primeros fragmentos de defer y recover
• Go Control Flow: Expression-Oriented Design - cómo defer encaja en el flujo orientado a expresiones
• if with Initialization & switch Patterns - abre archivos y luego difiere el cierre
• Control Flow Best Practices - cuándo no usar panic

Versiones de Stack: Esta página fue escrita para Go 1.26.x (GC por defecto Green Tea, go fix modernizers - verificar parche en build), chi (última - verificar en build), gin (última - verificar en build), echo (última - verificar en build), google.golang.org/grpc (última - verificar en build), sigs.k8s.io/controller-runtime (última - verificar en build), kubebuilder (última - verificar en build), tinygo (última - verificar objetivos de placa en build), wazero (última - verificar en build), y golangci-lint (última - verificar conjunto de linters en build).