RE: [Hibernate] HibernateException now a RuntimeException
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
[Hibernate] Missing Javadoc
public interface UserType {
public Object replace(Object original, Object target, Object owner)
throws HibernateException;
}
--
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
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
Re: [Hibernate] HibernateException now a RuntimeException
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
[Hibernate] HibernateException now a RuntimeException
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
[Hibernate] Collections of scalar values and collections of components
I think that collections of non-entities is actually working now. FooBarTest.testQuery() no longer errors, and if fails just at the end when it is doing a very complex query. I've cleaned up the tree parsers a bit by taking advantage of ANTLR grammar rule parameters. This is actually what allowed me to get the elements() function to work properly in both the WHERE context and the SELECT context. On the way I found that the way that PropertyMappings were handled was not quite right, so I've simplified and generalized it a little. This has eliminated some of the more complex code in FromElement, FromElementFactory, and elsewhere. Does anyone use 'checkstyle' any more? It seems that there a lot more checkstyle warnings than there were a few weeks ago. --- 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
