El operador ?: propagar errores con limpieza

Ya sabes construir, transformar y desenvolver Option y Result. Falta el gesto más frecuente de todos: cuando una función llama a otra falible y quiere propagar el fallo hacia arriba en lugar de manejarlo aquí. Hacerlo a mano con match es tan repetitivo que ensucia toda función no trivial. El operador ? colapsa ese patrón en un solo carácter, y al hacerlo revela por qué Option y Result no son dos tipos más de la biblioteca, sino la gramática misma sobre la que se escribe Rust.

Propagar a mano: el ruido del match

Considera una función que lee un fichero, lo recorta y lo devuelve. Cada paso puede fallar, y si falla, queremos devolver ese error al llamador. Escrito a mano:

fn leer_config() -> Result<String, std::io::Error> {
    let contenido = match std::fs::read_to_string("config.toml") {
        Ok(c) => c,
        Err(e) => return Err(e),   // propagamos el error tal cual
    };
    Ok(contenido.trim().to_string())
}

Ese match no aporta ninguna lógica: solo dice “si va bien, sigue con el valor; si va mal, devuélvelo ya”. Es puro ceremonial, y en una función con cinco pasos falibles se multiplica hasta enterrar lo que de verdad hace el código.

El operador ?: la propagación como puntuación

El operador ?, colocado tras una expresión que devuelve Result, hace exactamente eso: si es Ok(v), se evalúa a v y el programa sigue; si es Err(e), ejecuta return Err(e) inmediatamente. La misma función, con ?:

fn leer_config() -> Result<String, std::io::Error> {
    let contenido = std::fs::read_to_string("config.toml")?;   // desenvuelve o propaga
    Ok(contenido.trim().to_string())
}

Una línea, una intención. El ? desaparece visualmente pero mantiene el fallo completamente explícito: está ahí, en el carácter, y el tipo de retorno sigue siendo Result, así que el compilador te obliga a que la función entera sea honesta sobre su falibilidad. No es un try/catch disfrazado: es el cortocircuito de la vía ferroviaria de 7.4 elevado a sintaxis. Encadenar varios pasos se vuelve natural:

fn suma_del_fichero(ruta: &str) -> Result<i32, Box<dyn std::error::Error>> {
    let texto = std::fs::read_to_string(ruta)?;   // io::Error si falla
    let mut total = 0;
    for linea in texto.lines() {
        total += linea.trim().parse::<i32>()?;     // ParseIntError si falla
    }
    Ok(total)
}

? sobre Option, y la conversión con From

El ? también funciona sobre Option, con la simetría que ya esperas: si es Some(v), se evalúa a v; si es None, hace return None. Eso sí, dentro de una función que devuelva Option (no puedes propagar un None desde una función que devuelve Result, ni al revés):

fn primera_letra_mayus(s: &str) -> Option<char> {
    let primera = s.chars().next()?;   // si la cadena está vacía, return None
    Some(primera.to_ascii_uppercase())
}

Sobre Result hay un poder extra decisivo. Cuando propagas un Err(e) de tipo F desde una función cuyo error es de tipo E, el ? convierte F en E automáticamente llamando a From::from. Por eso el ejemplo anterior funcionaba: io::Error y ParseIntError son distintos, pero ambos se convierten a Box<dyn Error>. Con un tipo de error propio, tú provees las conversiones:

enum MiError {
    Io(std::io::Error),
    Parse(std::num::ParseIntError),
}

impl From<std::io::Error> for MiError {
    fn from(e: std::io::Error) -> Self { MiError::Io(e) }
}
impl From<std::num::ParseIntError> for MiError {
    fn from(e: std::num::ParseIntError) -> Self { MiError::Parse(e) }
}

fn cargar(ruta: &str) -> Result<i32, MiError> {
    let texto = std::fs::read_to_string(ruta)?;   // io::Error → MiError vía From
    let n: i32 = texto.trim().parse()?;           // ParseIntError → MiError vía From
    Ok(n)
}

flowchart TD
A[expresion seguida de interrogacion] --> B[Es Ok o Some]
A --> C[Es Err o None]
B --> D[Se desenvuelve y el programa sigue]
C --> E[return temprano con el error convertido por From]
E --> F[El llamador recibe el fallo tipado]
style B fill:#a6e3a1,color:#11111b
style C fill:#f38ba8,color:#11111b
style D fill:#89b4fa,color:#11111b
style F fill:#cba6f7,color:#11111b

Incluso main puede devolver Result, lo que permite usar ? en el nivel más alto de un programa:

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let contenido = std::fs::read_to_string("config.toml")?;
    println!("{contenido}");
    Ok(())   // si algo falla, main devuelve Err y el proceso sale con código ≠ 0
}

Option y Result como la base del estilo de Rust

Da un paso atrás y mira el nivel entero. Sin excepciones y sin null, Rust necesitaba una forma de expresar “esto podría no dar valor” y “esto podría fallar” que fuera ordinaria: un valor con tipo, visible en las firmas, verificado por el compilador. Esa forma son Option y Result. Y sobre esos dos tipos se levanta todo lo demás: los combinadores de 7.4 los transforman en tuberías, el ? los propaga sin ruido, y el #[must_use] impide olvidarlos. No es una biblioteca de manejo de errores pegada al lenguaje: es el estilo del lenguaje. Cuando leas código Rust idiomático, verás esta gramática por todas partes, y escribirla con fluidez es lo que separa traducir otro lenguaje a Rust de pensar en Rust.