Actually we kinda think the opposite :-) and we're not alone (see the Spring exception wrapper for example).
We consider checked exceptions as receverable contractual issues.
HibernateException have to be treated as not recoverable and the Tx has to be rollbacked. As stated by the EJB spec, only RTE are automatically rollbacked. BTW, how many applications you've developped can safely handle a down database. I only did 2 in my life, this is a pretty uncommon case.
Actually the Java platform itself is not consistent in its exception strategies.
I don't try to convince you, since it's hard on such a subject.
[EMAIL PROTECTED] wrote:
I searched the mailing list and I couldn’t find the reason for why the HibernateException was changed to a RuntimeException. If a failure occurs while persisting an object, for example if the database becomes unavailable, it would seem that the client should be forced to handle the failure. In other words, a RuntimeException is generally used for programming errors, while a checked exception is used when the client fulfilled their contract but an unexpected error occurs.
A persistence error seems to fall into the latter category. Based on this, as I would expect, in JDBC, a SQLException is a checked exception. How is the HibernateException different?
Thank you for the information.
Scott
-- Emmanuel Bernard [EMAIL PROTECTED] callto://emmanuelbernard
http://www.hibernate.org
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
