Respuesta.

El uso del tipo Result se ha convertido en uno de los enfoques clave para el manejo de errores en Rust. Históricamente, en muchos lenguajes, como C, los errores a menudo se señalaban mediante valores de retorno especiales o variables globales, lo que conducía a errores frecuentes al ignorar estas señales. Rust optó por la tipificación explícita de errores a través del enum Result<T, E>, lo que hace imposible ignorar accidentalmente un error: el compilador obliga a manejar ambas ramas (éxito y fracaso).

Problema: Se requería hacer que el manejo de errores fuera lo más seguro y legible posible, excluyendo errores "ocultos", así como aumentar la fiabilidad del código sin la necesidad de usar excepciones.

Solución: Result<T, E> es una enumeración con dos variantes: Ok(T) en caso de éxito y Err(E) en caso de error. Esto obliga a manejar explícitamente los errores o a ignorarlos mediante unwrap o esperar panics. Además, el operador ? hace que los patrones de propagación de errores sean concisos.

Ejemplo de código:

use std::fs::File;
use std::io::{self, Read};

fn read_file(path: &str) -> Result<String, io::Error> {
    let mut file = File::open(path)?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    Ok(contents)
}

Características clave:

Garantía de manejo de todas las variantes del resultado por parte del compilador.
Simplicidad en la cadena de propagación de errores a través del operador ?.
Posibilidad de definir tipos de errores personalizados y trabajar con errores sin excepciones.

Preguntas engañosas.

¿Siempre se puede usar el operador ? para la propagación automática de errores hacia arriba?

No, solo si el tipo de error de la función coincide con el tipo de la expresión a la derecha de ?. Si los tipos son incompatibles, se debe realizar una conversión explícita del error utilizando el método .map_err() o su tipo.

Ejemplo de código:

fn f() -> Result<(), String> {
    let _f = File::open("foo").map_err(|e| e.to_string())?;
    Ok(())
}

¿Se puede dejar el resultado de Result sin utilizar si simplemente no te interesa los errores?

No, el compilador emitirá una advertencia o un error si el resultado del tipo Result no se maneja. Debes llamar a .unwrap(), o bien llamar explícitamente a .ok()/.err()/let _ = ... o registrar el error correctamente.

¿Qué sucederá si llamas a .unwrap() en un Result con error?

Se producirá un panic! y la ejecución del programa se interrumpirá, lo que generalmente lleva a una terminación abrupta. Por lo tanto, unwrap() solo es aceptable cuando se garantiza que tendrá éxito.

Errores comunes y anti-patrones

Uso de unwrap() en código de producción (inseguro)
Ignorar errores (por ejemplo, let _ = ...;) sin registro
Incompatibilidad de tipos de error al usar "?", lo que lleva a errores de compilación confusos

Ejemplo de la vida real

Caso negativo

Un desarrollador decidió leer la configuración de un archivo y utilizó unwrap() en el resultado de la lectura.

Ventajas:

Mínimo código, rápida creación de prototipos

Desventajas:

En caso de que falte el archivo, la aplicación se bloquea sin un mensaje claro para el usuario
Difícil de depurar más adelante

Caso positivo

Los errores al leer la configuración se registran y se devuelven hacia arriba en la pila de llamadas utilizando Result + operador ?.