Revisando las excepciones checked de Java: una función de seguridad de tipos subestimada

Resumen de puntos clave

• Aunque las excepciones checked de Java son una función ampliamente criticada en la comunidad, tienen ventajas sobresalientes desde la perspectiva de la seguridad de tipos.
• Ofrecen un mecanismo de seguridad de tipos conceptualmente similar a Result<T, E> de Rust o Either a b de Haskell.
• Las excepciones checked expresan de forma explícita en la firma del método la posibilidad de una falla potencial, obligando al manejo de errores a través del sistema de tipos.

Ventajas de las excepciones checked

• Proporcionan seguridad de tipos al verificar en tiempo de compilación si una excepción fue manejada.
• Hacen que la posibilidad de una excepción forme parte del contrato de la API al declararla con una cláusula throws en la firma del método.
• Ofrecen un mecanismo conveniente en el que, con solo declararlas, las excepciones se propagan automáticamente.
• A diferencia de Rust, no requieren sintaxis adicional como el operador ? en cada llamada.

Problemas de las excepciones checked

• Generan demasiado código boilerplate en la cadena de llamadas.
• Tienen poca compatibilidad con la programación funcional, como las lambdas y la API de streams introducidas desde Java 8.
• Dificultan la evolución de las API porque agregar una nueva excepción a una interfaz rompe la compatibilidad.
• Pueden fomentar antipatrones que ignoran las excepciones.

Propuestas de mejora

• Mejorar las interfaces funcionales para que las lambdas puedan declarar excepciones checked.
• Añadir soporte para tipos de excepción genéricos en la cláusula throws.
• Ampliar la API para manejar mejor las excepciones checked en contextos funcionales.
• Lograr una mejor integración con las API de Optional<T> y Stream<T>.

Comparación con otros lenguajes

• Rust: ofrece un mecanismo explícito de manejo de errores mediante Result<T, E> y el operador ?.
• Kotlin: convirtió todas las excepciones en unchecked, pero ofrece estructuras funcionales como runCatching.
• Scala: admite manejo funcional de errores mediante tipos monádicos como Try[T] y Either[A, B].

Conclusión

• Las excepciones checked necesitan ser reevaluadas como una función innovadora y mal entendida de Java.
• En lugar de abandonarlas por completo, sería deseable mejorarlas para que encajen bien con las funciones modernas de Java.
• Existe la posibilidad de evolucionarlas hacia la resolución de problemas prácticos manteniendo el paradigma existente.
• Es importante encontrar un punto de equilibrio entre seguridad de tipos, concisión del código y flexibilidad.

[roxie]

Siento que estaba repitiendo un debate del que ya se habló durante más de una década. Parece una afirmación de que las excepciones tienen tanto valor como los tipos, y yo quisiera responder que con los tipos es suficiente.