Result, Option y el operador ?: manejo de errores en Rust

Qué es

Result<T, E> es un enum con Ok(T) y Err(E); Option<T> tiene Some(T) y None. No existe el puntero nulo ni el desempaquetado implícito: para usar el valor interno, el código debe emplear match, if let o llamar a un método como unwrap_or, map, and_then u ok_or. unwrap() y expect("...") extraen el valor y, si no lo hay, provocan un panic. El libro de Rust describe el operador de interrogación: expr? sobre un Result devuelve Err de forma anticipada desde la función que lo contiene, tras pasar el error por el trait From hacia el tipo de error declarado de la función; sobre un Option devuelve None. Solo puede usarse en una función cuyo tipo de retorno sea compatible, y main puede devolver Result<(), Box<dyn Error>> para permitirlo en el nivel superior. La documentación de la biblioteca estándar indica que Result está anotado con #[must_use], por lo que un Result que no se asigna ni se usa provoca una advertencia del compilador.

Por qué importa

En el código basado en excepciones, un fallo puede propagarse hacia arriba sin que se vea; la firma de una función de Python no dice nada sobre lo que puede lanzar. En Rust, la posibilidad de fallo forma parte del tipo de retorno, el compilador no permite olvidarla y el mismo mecanismo cubre los valores ausentes, con lo que desaparece la clase de errores de un None devuelto inesperadamente. Los panics existen, pero están pensados para invariantes que la entrada no puede violar, no para fallos esperables.

Cómo aplicarlo

• Devuelve Result en todo lo que toque E/S, análisis sintáctico (parsing) o datos de usuario; devuelve Option en las búsquedas donde la ausencia es normal.
• Define un enum de errores por crate o módulo, con una variante por causa, implementa std::error::Error y Display, e implementa From para los errores subyacentes de modo que ? convierta automáticamente; crates como thiserror generan este código repetitivo.
• En el código de aplicación suele bastar un tipo de error opaco que lleve contexto (como el que ofrece el crate anyhow); las bibliotecas deben exponer errores tipados sobre los que quien las llama pueda hacer match.
• Reserva unwrap y expect para las pruebas y para los casos en que el mensaje de expect declara la invariante.
• Usa combinadores para cadenas cortas y match cuando cada rama hace algo distinto.

Trampas

? dentro de un closure se aplica al closure, no a la función exterior. Convertirlo todo pronto a Box<dyn Error> hace perder la posibilidad de distinguir las causas con match. let _ = fallible(); silencia la advertencia de must-use y descarta el error. Mezclar Option y Result en una misma cadena requiere ok_or o transpose.

Qué errores pueden usar From directamente

La conversión automática mediante From conserva lo que dice el error interno y nada más. Eso basta para los errores que ya nombran su objeto (un error de análisis con su posición, un error de cliente con la URL). No basta para std::io::Error, que no incluye ni la ruta ni la operación, de modo que ? con From<io::Error> produce 'No such file or directory' sin indicar ningún archivo. En esos casos, añade el contexto en el punto de la llamada: una variante de thiserror como #[error("reading {path}")] Io { path: PathBuf, #[source] source: std::io::Error } rellenada mediante map_err, o, en código de aplicación, .with_context(|| format!("reading {}", path.display())) de anyhow. Regla práctica: una implementación de From por cada tipo de error que se describe a sí mismo; map_err o with_context en cada llamada de E/S.