En el desarrollo de software, la gestión de errores es crucial para la experiencia del usuario y la fiabilidad del sistema. Evan Hahn, en su artículo, propone una clasificación fundamental de los errores en dos categorías: errores esperados y errores inesperados. Esta distinción, aunque aparentemente simple, tiene implicaciones profundas en cómo abordamos el manejo de errores.
Errores Esperados: Estos son errores que se anticipan como parte del funcionamiento normal del programa. Incluyen situaciones como errores de validación de datos ingresados por el usuario (el usuario puede ingresar información incorrecta), fallos de red (la conexión a Internet puede fallar), o restricciones de permisos (el programa no puede acceder a ciertos recursos). La clave aquí es que el desarrollador no ha cometido un error en sí mismo; estos problemas son inherentes al entorno o a la interacción con el usuario. La solución correcta es no hacer que el programa se bloquee. En cambio, se deben manejar estos errores, registrando una advertencia (WARN o INFO en los logs), mostrando un mensaje informativo al usuario o utilizando un mecanismo de respaldo (fallback). La idea es permitir que el programa continúe funcionando, aunque quizás con una funcionalidad reducida.
Errores Inesperados: Estos son errores que no deberían ocurrir bajo ninguna circunstancia. Son indicativos de un fallo en la lógica del programa, un bug. Ejemplos incluyen errores de aserción (una condición que se espera que sea siempre verdadera, pero que no lo es), errores de lógica (dependencias incorrectas entre componentes), o incluso errores de datos (recibir datos inválidos de una base de datos). Cuando se produce un error inesperado, la mejor respuesta es, según Hahn, que el programa se bloquee (crash, panic, throw). Esto puede parecer contraintuitivo, pero la justificación es que un fallo abrupto es preferible a un comportamiento impredecible o corrupto. Los errores inesperados deben registrarse con mensajes ERROR o FATAL.
La Línea Divisoria: La clasificación entre error esperado e inesperado es contextual. En un prototipo rápido, casi todos los errores pueden considerarse inesperados y no se molestará en manejarlos. Por el contrario, en sistemas críticos como una sonda espacial con una misión de 50 años, casi todos los errores deben ser considerados esperados y manejados con cuidado. La tendencia general, para mejorar la fiabilidad, es esperar más errores.
Implicaciones Técnicas: Esta filosofía de manejo de errores influye en la elección del lenguaje de programación. Lenguajes como Rust y Zig, que fuerzan el manejo de errores, se alinean con esta visión. Otros, como JavaScript y Python, tienden a tratar más errores como inesperados. La adopción de esta perspectiva puede llevar a un código más robusto y a una mejor comprensión de los posibles fallos en un sistema.