unwrap y expect: el panic explícito y sus alternativas seguras

unwrap y expect son el puente entre los dos mundos de fallo del nivel. Toman un Result o un Option —un fallo modelado como valor recuperable— y lo colapsan en su contenido, entrando en panic! si el fallo se materializa. Es decir: convierten deliberadamente un error recuperable en uno irrecuperable. Esa conversión es a veces exactamente lo correcto y a menudo un error de diseño con nombre propio: el crash en producción a las tres de la madrugada. La madurez en Rust no consiste en evitarlos siempre, sino en saber cuándo cada unwrap es una afirmación probada y cuándo es una bomba de relojería, y en escribir con expect la prueba que justifica el atrevimiento.

Qué hacen, y por qué son peligrosos

unwrap sobre Some(v) u Ok(v) devuelve v; sobre None o Err(e) entra en panic!. Sobre un Result, el mensaje incluye el error vía Debug; sobre un Option, un genérico “called Option::unwrap() on a None value”. Gracias a #[track_caller], el pánico apunta a tu línea, no a las tripas de la biblioteca.

let config = std::fs::read_to_string("config.toml").unwrap();  // panic si el fichero no esta
let puerto: u16 = env_var.parse().unwrap();                    // panic si no es un numero

El peligro no es sintáctico, es conceptual. Cada uno de esos unwrap toma un fallo perfectamente esperable —un fichero ausente, una variable mal formada— y lo trata como un bug irrecuperable. Roba a quien llama la posibilidad de reaccionar, borra el contexto del error, y transforma una condición del mundo en una caída del proceso. Es el anti-patrón exacto de la primera lección: usar panic! donde correspondía Result. Un unwrap sin justificar es una promesa que no has demostrado.

expect: el panic como documentación de la invariante

expect es unwrap con un mensaje, y ese mensaje es donde vive la buena ingeniería. La convención de la biblioteca estándar es contraintuitiva y vale oro: el mensaje no describe el error, sino la razón por la que esperabas éxito —la invariante que juras cierta—. Se lee como un “debería”, una promesa que justifica el atrevimiento.

// Mal: describe el sintoma, redundante con el propio panico.
let clave = std::env::var("API_KEY").expect("fallo al leer API_KEY");

// Bien: describe la invariante que garantiza el exito.
let clave = std::env::var("API_KEY")
    .expect("API_KEY debe estar definida: la exporta el script de arranque");

El segundo mensaje convierte el pánico en documentación: quien lo lea en un log entiende qué promesa se rompió y dónde buscar la causa (el script de arranque), no solo que algo falló. Un expect bien redactado es un comentario que el compilador no puede dejar desactualizado, porque vive pegado a la operación que protege.

Cuándo son legítimos, y las alternativas seguras

Hay contextos donde unwrap y expect son la herramienta correcta:

Fuera de esos casos, hay una alternativa segura para cada intención, y la decisión sigue un árbol sencillo:

flowchart TD
Q[Tengo un Result o un Option] --> A[El fallo es esperable del mundo]
Q --> B[El fallo seria un bug aqui]
A --> A1[Propaga con interrogacion o maneja con unwrap_or]
B --> B1[Puedo enunciar la invariante que lo hace imposible]
B1 --> C[Si la escribo como mensaje uso expect]
B1 --> D[Si no puedo enunciarla no era una invariante]
D --> A1
style Q fill:#cba6f7,color:#11111b
style A fill:#a6e3a1,color:#11111b
style B fill:#f38ba8,color:#11111b
style C fill:#89b4fa,color:#11111b

Si tienes un valor por defecto sensato, unwrap_or(x), unwrap_or_else(|| ...) (perezoso) o unwrap_or_default(). Si el fallo debe subir, ?. Si quieres darle causa a una ausencia, ok_or/ok_or_else. Y para desenvolver con manejo del caso negativo sin anidar, let ... else:

fn primer_par(v: &[i32]) -> i32 {
    let Some(&n) = v.iter().find(|x| *x % 2 == 0) else {
        return -1;   // maneja la ausencia y sigue sin panico ni anidamiento
    };
    n
}

Para blindar una base de código, las lints clippy::unwrap_used y clippy::expect_used señalan cada aparición para revisión. Y recuerda a los primos de unwrap en la familia del pánico deliberado —unreachable!, todo!, unimplemented!—, cada uno una forma distinta de decir “aquí el fallo es un bug, no una condición”. El unwrap_unchecked existe, es unsafe, y traslada la afirmación al terreno donde tú respondes por ella sin red.