Rust dispone de múltiples estrategias para tratar errores en una función: provocar un pánico con expect, devolver un Option<T>, retornar un Result<T, E> enriquecido con contexto, o recuperar la ejecución sustituyendo el valor fallido por uno por defecto (por ejemplo, unwrap_or(0)). Esta última resulta especialmente útil cuando una operación puede completarse aunque algún paso intermedio falle, una situación frecuente en compiladores, intérpretes de rutas, suites de pruebas o evaluadores de expresiones. Sin embargo, el patrón de recuperación presenta un problema: la persona que llama a la función no tiene forma de saber si hubo un fallo interno, ya que la firma del tipo no lo refleja.
El lenguaje Go resuelve esta tensión devolviendo una tupla (valor, error); replicar ese enfoque en Rust produce un código poco ergonómico y cuya firma tampoco comunica la posibilidad de fallo. Para solucionarlo, el artículo propone un conjunto de requisitos: continuar con un valor por defecto, mantener la lógica del camino feliz como dominante, reflejar en la firma la posibilidad de error, permitir devolver varios errores, componerse con el manejo tradicional de Rust y consigo mismo, y permitir retornos anticipados.
La primera solución concreta es el "parámetro de error": pasar a la función un argumento que recoja los errores de forma centralizada, útil cuando se quieren acumular fallos de toda una fase de la aplicación. Esta estrategia admite diversas variantes en su implementación.