On Jan 24, 2005, at 12:45 AM, <[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.
No, an unchecked exception should be used for fatal errors, since it makes no sense to force the client to catch it at every level. You catch fatal exceptions at the top of your call stack and present an error message (or take other appropriate actions). Hibernate exceptions are always fatal.
This has been discussed a hundred times in the Java community, use Google. The checked exceptions in Hibernate2 and the in JDBC are a mistake. Everyone wraps HibernateException in a RuntimeException these days, so we made it the default. You can still catch and rethrow if you like, its declared on all methods that throw it.
-- Christian Bauer +49 171 455 66 53 callto://christian-bauer
Hibernate [EMAIL PROTECTED] http://hibernate.org
JBoss Inc [EMAIL PROTECTED] http://jboss.com
------------------------------------------------------- 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
