I think that this might be an issue on which we'll have to agree to disagree.
I personally think that a database exception is recoverable. Especially in the case of large applications in which several databases can be used for different purposes. If one goes down, large portions of the application may still function. I can also see a case in which the database transaction is only a portion of the process. And, if that database transaction fails, the previous steps in the process must also be rolled back. In this case, the developer is forced to a catch a Runtime exception, which is considered bad practice. I also feel that whenever there's a doubt that a client may or may not be able to recover, you should err on the side of caution and give the client a chance. That's why I save Runtime exceptions for api misuse and developer errors only. Scott > -----Original Message----- > From: Emmanuel Bernard [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 23, 2005 4:03 PM > To: [EMAIL PROTECTED] > Cc: hibernate-devel@lists.sourceforge.net > Subject: Re: [Hibernate] HibernateException now a RuntimeException > > Hi Scott, > 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
