Respuesta a la pregunta.
Historia de la pregunta
El manejo de errores en C++ se basó tradicionalmente en excepciones o códigos de error. Las excepciones proporcionaron una sintaxis limpia, pero incurrieron en sobrecarga en tiempo de ejecución y fueron difíciles de usar en contextos deterministas como sistemas embebidos o comercio en tiempo real. Los códigos de error eran eficientes, pero contaminaban las firmas de las funciones y requerían verificación manual de propagación. C++23 introdujo std::expected, un tipo de vocabulario que representa un valor o un error, inspirado en monadas de programación funcional como Either de Haskell o Result de Rust.
El problema
Si bien std::expected proporciona operaciones monádicas como and_then, or_else y transform, estas operaciones requieren un manejo explícito del tipo de error en cada paso de la cadena de composición. A diferencia del manejo basado en excepciones donde los errores se propagan automáticamente por la pila de llamadas hasta ser capturados, std::expected requiere que el programador especifique explícitamente cómo los errores se transforman o propagan a través de cada enlace monádico. Esta explicitud crea código verboso al encadenar múltiples operaciones que podrían fallar, y requiere una consideración cuidadosa de las conversiones de tipo de error cuando diferentes operaciones devuelven diferentes tipos de error. El problema fundamental es que el sistema de tipos de C++ requiere una unificación explícita del tipo de error en las instanciaciones de plantillas, a diferencia del manejo dinámico de excepciones.
La solución
La interfaz monádica de std::expected de C++23 utiliza maquinaria de plantillas explícita para garantizar la seguridad de tipos y la abstracción sin sobrecarga. El método and_then requiere que el llamador devuelva otro std::expected con tipos de error potencialmente diferentes, y la implementación utiliza SFINAE o conceptos para validar la composición. Para la propagación del tipo de error, los desarrolladores deben manejar explícitamente las conversiones de tipo utilizando or_else o mapear tipos de error utilizando transform_error. Este enfoque explícito asegura que los caminos de manejo de errores sean visibles en el código fuente y optimizables por el compilador, a diferencia del flujo de control de excepciones ocultas. La solución adopta principios de programación funcional mientras respeta la filosofía de cero sobrecarga de C++.
#include <expected> #include <string> #include <system_error> std::expected<int, std::error_code> parse_int(const std::string& s); std::expected<double, std::error_code> divide(int a, int b); // Manejo de errores explícitos en la composición auto result = parse_int("42") .and_then([](int n) { return divide(100, n); }) .or_else([](std::error_code e) { return std::expected<double, std::error_code>(0.0); });
Situación de la vida real
Un equipo de software de dispositivos médicos necesitaba implementar un pipeline de datos para procesar lecturas de sensores con múltiples etapas de validación. Cada etapa podría fallar con códigos de error específicos (tiempo de espera de hardware, fallo de suma de verificación, error de calibración) que necesitaban propagarse al sistema de registro con total seguridad de tipos.
El primer enfoque considerado fue el manejo de errores basado en excepciones utilizando la jerarquía de std::runtime_error. Esto permitió la propagación automática a través de la pila de llamadas y una separación limpia del manejo de errores de la lógica de negocios. Sin embargo, los dispositivos médicos requerían garantías de latencia determinista, y las excepciones introducían sobrecargas impredecibles durante el desanidado de la pila. El enfoque también hacía imposible utilizar el código en kernels de GPU o en contextos embebidos donde las excepciones estaban deshabilitadas. El equipo necesitaba una solución que funcionara en entornos noexcept.
El segundo enfoque considerado fueron los códigos de error tradicionales utilizando std::optional o std::variant con verificación manual de errores después de cada operación. Esto proporcionó el determinismo requerido y la compatibilidad noexcept. Sin embargo, el código se volvió desordenado con repetitivos chequeos if (!result) después de cada etapa del pipeline. La propagación de errores requería un hilo manual de códigos de error a través de la pila de llamadas, y componer múltiples operaciones requería condicionales anidados que oscurecían la lógica de flujo de datos. Los tipos de error también carecían de seguridad de tipos al mezclar diferentes categorías de errores de varios sensores de hardware.
La solución elegida fue std::expected de C++23 con su interfaz monádica. El equipo refactorizó el pipeline para usar and_then para encadenar los pasos de validación y or_else para la transformación de errores. Esto preservó el flujo de datos lineal mientras mantenía caminos de manejo de errores explícitos. La solución proporcionó una abstracción sin sobrecarga compatible con las restricciones noexcept y permitió una precisa propagación del tipo de error al sistema de registro. La refactorización tomó tres semanas, después de lo cual la base de código soportaba 15 tipos diferentes de sensores con un manejo de errores unificado.
Qué a menudo los candidatos pasan por alto
¿Cómo maneja std::expected la eliminación de tipos al encadenar operaciones que devuelven diferentes tipos de error?
Los candidatos a menudo pasan por alto que std::expected no realiza eliminación de tipos por defecto. Al usar and_then, el llamador debe devolver un std::expected con el mismo tipo de error que el original, o el programa no compila.
Para manejar diferentes tipos de error, los desarrolladores deben transformar explícitamente los errores utilizando transform_error o usar std::expected con una variante de tipo de error común. A diferencia de las excepciones que utilizan un solo tipo estático para todos los errores (generalmente std::exception_ptr o clases base de excepciones), std::expected mantiene estricta seguridad de tipos.
Este diseño previene costos ocultos de eliminación de tipos, pero requiere una unificación explícita del tipo de error en tiempo de compilación. Comprender esta distinción es crucial para componer operaciones de diferentes bibliotecas con distintas categorías de errores.
¿Por qué std::expected no proporciona una operación de enlace monádico que propague automáticamente errores como lo hace el manejo de excepciones?
Los candidatos a menudo confunden std::expected con el manejo de errores basado en excepciones en cuanto a la propagación automática. Esperan que si una operación en una cadena falla, las operaciones subsiguientes se salten automáticamente sin manejo explícito.
Mientras que and_then omite el llamador en caso de error, el tipo de error aún debe manejarse explícitamente al final de la cadena o transformarse usando or_else. La razón fundamental es que el sistema de tipos de C++ requiere un manejo explícito de todos los posibles estados de error para mantener un comportamiento sin sobrecarga y determinista.
La propagación automática requeriría un flujo de control implícito similar a las excepciones, lo que contradice el objetivo de diseño de caminos de error explícitos y optimizables. std::expected prioriza el rendimiento y la seguridad de tipos sobre la conveniencia sintáctica.
¿Cómo afecta la especificación noexcept de las operaciones monádicas de std::expected a las garantías de seguridad de excepciones en las cadenas de composición?
Los candidatos a menudo pasan por alto que las operaciones monádicas de std::expected como and_then y transform son condicionalmente noexcept en función de las operaciones que invocan. Si el llamador pasado a and_then es noexcept, toda la cadena permanece noexcept.
Sin embargo, si el llamador puede lanzar, la operación puede lanzar std::bad_expected_access o propagar la excepción dependiendo de la implementación específica y la estrategia de manejo de errores. Esta propagación condicional noexcept permite a los desarrolladores mantener fuertes garantías de seguridad de excepciones a lo largo de la cadena de composición.
Comprender esto es crucial para sistemas en tiempo real donde las especificaciones de excepciones afectan la generación de código y la optimización. El contrato noexcept se propaga a través de la cadena monádica, asegurando que el manejo de errores permanezca determinista y optimizable por el compilador.