panic y recover en Go: panics en tiempo de ejecución y cuándo usarlos

Qué aspecto tiene un panic

Un panic detiene la función actual, ejecuta sus llamadas diferidas, luego hace lo mismo en la función que la llamó, y así sucesivamente hacia arriba por la pila. Si llega a la parte alta de la goroutine, el programa cae.

package main

import "fmt"

func main() {
	defer fmt.Println("deferred in main: still runs")

	nums := []int{1, 2, 3}
	i := 5
	fmt.Println("before")
	fmt.Println(nums[i]) // panics
	fmt.Println("never printed")
}

Este programa sale con estado 2. La salida es:

before
deferred in main: still runs
panic: runtime error: index out of range [5] with length 3

goroutine 1 [running]:
main.main()
	/tmp/main.go:11 +0x...
exit status 2

La llamada diferida se ejecutó antes del informe de la caída. La traza nombra la goroutine, la función y la línea, lo que suele bastar para encontrar el bug.

Panics habituales del runtime

Cada uno de ellos es un bug del programa, no una condición que haya que manejar. El arreglo es una comprobación de límites, una comprobación de nil, un make o una aserción comma-ok, no un recover.

Recuperar

recover() detiene un panic. Solo funciona cuando se llama directamente dentro de una función diferida, porque las funciones diferidas son el único código que se ejecuta mientras un panic deshace la pila.

package main

import "fmt"

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

func main() {
	fmt.Println(safeDivide(10, 2))
	fmt.Println(safeDivide(1, 0))
	fmt.Println("program continues")
}

Salida:

5 <nil>
0 recovered: runtime error: integer divide by zero
program continues

Qué pasó en la segunda llamada:

1. a / b provocó un panic.
2. Se ejecutó la closure diferida, y recover() devolvió el valor del panic (un runtime.Error).
3. Se detuvo el deshacer de la pila. safeDivide retornó con normalidad a main, con el resultado con nombre err asignado por la closure.

El resultado con nombre es lo que permite a la función diferida devolver un error. Sin él, la función devuelve sus valores cero. La página de defer explica cómo las closures diferidas modifican los resultados.

recover() devuelve nil cuando no hay panic, así que la comprobación if r != nil hace que la función diferida sea inofensiva en la ruta normal. Llamado fuera de una función diferida, o en una función llamada por la función diferida, recover devuelve nil y no hace nada.

panic con tu propio valor

panic acepta cualquier valor. Lo típico es un error o un string.

package main

import (
	"errors"
	"fmt"
)

var ErrInvariant = errors.New("invariant violated")

func mustPositive(n int) int {
	if n <= 0 {
		panic(fmt.Errorf("mustPositive(%d): %w", n, ErrInvariant))
	}
	return n
}

func main() {
	defer func() {
		r := recover()
		if err, ok := r.(error); ok && errors.Is(err, ErrInvariant) {
			fmt.Println("caught:", err)
			return
		}
		if r != nil {
			panic(r) // not ours: re-panic
		}
	}()

	fmt.Println(mustPositive(3))
	fmt.Println(mustPositive(-1))
}

Recupera lo que esperas y vuelve a provocar el panic con todo lo demás. Tragarse todos los panics esconde bugs reales.

Desde Go 1.21, panic(nil) se convierte en un *runtime.PanicNilError, así que ahora que recover() devuelva nil significa con seguridad "no hubo panic".

Panics en goroutines

recover solo captura los panics de su propia goroutine. Un panic en cualquier goroutine sin recover mata el proceso entero, incluidos main y todas las demás goroutines.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, name string, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %s panicked: %v\n", name, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, "ok", func() { fmt.Println("worker ok done") })
	safeGo(&wg, "bad", func() {
		var m map[string]int
		m["x"] = 1
	})
	wg.Wait()
	fmt.Println("main finished")
}

Las dos líneas de los workers pueden imprimirse en cualquier orden; main finished siempre sale la última. Un defer recover() en main no habría salvado al programa del segundo worker. Por eso los servidores HTTP recuperan por petición: net/http recupera los panics en la goroutine de cada handler, los registra y cierra esa conexión, para que una petición defectuosa no tumbe el servidor.

Algunos fallos son errores fatales, no panics, y no se pueden recuperar de ninguna forma: concurrent map writes, quedarse sin memoria y el all goroutines are asleep del detector de deadlocks.

Cuándo un panic es la decisión correcta

La regla general de Go: devuelve errores para todo lo que puede ir mal en tiempo de ejecución, y provoca un panic solo ante errores del programador. En concreto, un panic es adecuado cuando:

• Se rompe un invariante. Un switch sobre tu propio enum llega a un caso que no puede ocurrir. Continuar corrompería datos.
• Una función auxiliar Must recibe una entrada constante incorrecta. regexp.MustCompile, template.Must y uuid.MustParse envuelven una función que devuelve un error y provocan un panic si falla. Úsalas para valores conocidos en tiempo de compilación, normalmente variables a nivel de paquete, donde un fallo significa que el código fuente está mal:

var emailRE = regexp.MustCompile(`^[^@\s]+@[^@\s]+$`)

• El arranque no puede continuar. Falta configuración obligatoria en main. Incluso aquí, imprimir el error y llamar a os.Exit(1) suele quedar más limpio que una traza de la pila.

Un panic es la herramienta equivocada para:

• Fallos esperados: entrada de usuario no válida, un archivo que falta, un timeout. Devuelve un error; consulta manejo de errores.
• Flujo de control: usar panic y recover como excepciones a lo largo de un árbol de llamadas grande hace el código difícil de seguir. La librería estándar lo hace internamente en un par de sitios (el encoder de encoding/json), siempre recuperando antes de retornar, así que ningún panic sale del paquete.
• APIs de librerías: una librería que provoca un panic ante una entrada incorrecta obliga a cada llamador a añadir recovers. Devuelve un error.

Errores comunes

• Llamar a recover fuera de una función diferida. Devuelve nil.
• Recuperar en main el panic de una goroutine. Cada goroutine necesita el suyo.
• Tragarse todos los panics. Registra la pila (debug.Stack() de runtime/debug) y vuelve a provocar el panic con lo que no esperabas.
• Usar recover para manejar escrituras en maps nil o índices fuera de rango. Arregla el bug.