por qué Hibernate cambió HibernateException a (sin marcar) RuntimeException

Question

Sé que en algunas versiones las excepciones de Hibernate se cambiaron para desmarcarlas. ¿cual es la razon? ¿Es este un tema de filosofía o práctico?

Answer 1

Práctico. Por lo tanto, no tiene que ajustar todas sus operaciones con respecto a Hibernate en los bloques de captura de prueba.

Tomado de Java Persistence con Hibernate:

Una historia de excepciones - Excepciones y cómo deben ser manejados siempre fin en encendidos debates entre Java desarrolladores. No es de extrañar que Hibernate también tenga una historia digna de mención . Hasta Hibernate 3.x, todas las excepciones lanzadas por Hibernate eran excepciones comprobadas , por lo que cada Hibernate API forzó al desarrollador a detectar y manejar excepciones. Esta estrategia fue influenciada por JDBC, que también lanza solo marcó excepciones. Sin embargo, pronto quedó claro que esto no tiene sentido, porque todas las excepciones lanzadas por Hibernate son fatales. En muchos casos , lo mejor que puede hacer un desarrollador en esta situación es limpiar, mostrar un mensaje de error y salir de la aplicación . Por lo tanto, comenzando con Hibernate 3.x, todas las excepciones lanzadas por Hibernate son subtipos de la excepción de ejecución sin control, que es maneja generalmente en una única ubicación en una aplicación. Esto también hace obsoleta a cualquier plantilla de Hibernate o API de contenedor .