panic!: el fallo irrecuperable y su maquinaria

Rust parte los fallos en dos mundos irreconciliables. Uno es el de los errores esperables —el fichero que no está, la red que se cae— y se modela con Result, un valor que viaja por la firma. El otro es el de los fallos que no deberían poder ocurrir jamás: un índice fuera de rango, una invariante que tu propia lógica juró mantener y rompió. Para ese segundo mundo existe panic!. No es un throw disfrazado ni un mecanismo de control de flujo: es la declaración de que el programa ha alcanzado un estado imposible y que continuar sería peor que detenerse. Entender su maquinaria —qué desenrolla, qué destruye, qué se puede atrapar y qué no— es entender la frontera exacta entre un bug y una condición.

Qué es un panic, y qué no es

Un panic! señala un error de programación, no una condición del entorno. La regla de las directrices de la API oficial es tajante: usa Result cuando el fallo forma parte del contrato razonable de la función, y panic! cuando el fallo significa que una precondición se ha violado y no hay contrato que respetar. panic!, assert!, indexar un Vec fuera de rango, un desbordamiento aritmético en debug, o un unwrap sobre None: todos convergen en el mismo mecanismo.

fn media(datos: &[f64]) -> f64 {
    assert!(!datos.is_empty(), "media de un slice vacio: invariante rota");
    datos.iter().sum::<f64>() / datos.len() as f64
}

El assert! no valida entrada del usuario; valida una invariante interna que el resto del código promete mantener. Si se dispara, no hay recuperación sensata: el programa ya está en un estado que su autor consideró imposible. Compáralo con parsear un número que teclea el usuario, que es un Result, porque teclear basura es un evento perfectamente normal.

Desenrollado frente a aborto: las dos estrategias

Cuando un panic! ocurre, Rust puede reaccionar de dos maneras, y la elección es del perfil de compilación, no del código.

Con desenrollado (unwind, el modo por defecto en std), el hilo que entró en pánico recorre su pila hacia arriba ejecutando todos los destructores (Drop) de los valores vivos en cada marco, liberando recursos con orden, hasta llegar a la raíz del hilo. Si es el hilo principal, el proceso termina; si es un hilo secundario, solo muere ese hilo y el resto del programa sigue. Ese recorrido ordenado tiene un coste: el compilador debe emitir tablas de desenrollado (las secciones tipo .eh_frame) y puntos de aterrizaje que engordan el binario y atan levemente las manos al optimizador.

Con aborto (abort), no hay recorrido: el proceso muere en el acto con una señal (SIGABRT), sin ejecutar un solo destructor. Se activa así:

# Cargo.toml
[profile.release]
panic = "abort"

El aborto produce binarios más pequeños y sin tablas de desenrollado, razón por la que es el modo natural en embebido, no_std, núcleos y contextos donde el desenrollado es un lujo inaceptable. El precio es que pierdes la limpieza ordenada y la capacidad de atrapar el pánico.

Hay una frontera más, crítica desde Rust 1.81: si el desenrollado alcanza un límite extern "C", el proceso aborta, porque desenrollar a través de una ABI que no lo contempla sería comportamiento indefinido. Para permitir el desenrollado a través de la frontera —interoperar con C++ que sí desenrolla— existe la ABI explícita extern "C-unwind".

flowchart TD
P[panic invocado] --> U[Estrategia unwind]
P --> A[Estrategia abort]
U --> D[Ejecuta destructores subiendo por la pila]
D --> C[catch_unwind puede atrapar en un limite de hilo]
A --> K[Aborta de inmediato sin destructores]
K --> S[Binario menor sin tablas de desenrollado]
style P fill:#f38ba8,color:#11111b
style U fill:#89b4fa,color:#11111b
style A fill:#cba6f7,color:#11111b
style C fill:#a6e3a1,color:#11111b

La maquinaria: hooks, catch_unwind y track_caller

Antes de desenrollar, Rust invoca el hook de pánico. El por defecto imprime en stderr el mensaje, la ubicación del panic! y —si RUST_BACKTRACE=1— la traza de pila. Puedes reemplazarlo con std::panic::set_hook, cuyo cierre recibe un &PanicHookInfo (nombre que en std sustituyó al antiguo PanicInfo a partir de Rust 1.81, para separarlo del core::panic::PanicInfo que usa #[panic_handler]).

std::panic::set_hook(Box::new(|info| {
    eprintln!("fallo fatal registrado: {info}");
}));

Sobre el desenrollado se construye catch_unwind, que ejecuta un cierre y atrapa un pánico convirtiéndolo en un Result:

use std::panic;

let resultado = panic::catch_unwind(|| {
    procesar_peticion()   // si entra en panico, no derriba el proceso
});
match resultado {
    Ok(v) => v,
    Err(_causa) => registrar_y_seguir(),   // el hilo sobrevive
}

No es un try/catch: su propósito legítimo es aislar fallos en fronteras —un servidor que no quiere que un pánico en una petición tumbe a las demás, o exponer una API a C sin dejar escapar el desenrollado—. Exige que lo capturado sea UnwindSafe (o que lo afirmes con AssertUnwindSafe), una salvaguarda contra observar estados a medio romper. Y bajo panic = "abort" no atrapa nada, porque no hay desenrollado que interceptar. Para relanzar el pánico intacto, panic::resume_unwind.

Un último detalle de ergonomía: #[track_caller]. Funciones como unwrap lo llevan para que, al entrar en pánico, la ubicación reportada sea la de quien las llamó, no la de la línea interna de la biblioteca. std::panic::Location::caller() expone esa información. En no_std, por último, no hay hook por defecto: tú provees el comportamiento con una función #[panic_handler] que recibe &PanicInfo y no retorna nunca (-> !).