Hibernate3.x.x


Why the HibernateException.java extends RuntimeException since version 3.x.x?

I think it is not a good choice,because you'll not be fored to throw a HibernateExcetion when you are coding with Hibernate3.x.x,for example.

The Class DAO was written by user A who isn't a careful person,the source code of DAO.java may be:

class DAO{

pubic void create(Session session,Object obj){
session.save(obj);
}

}

but not

class DAO{

pubic void create(Session session,Object obj) throws HibernateException{
session.save(obj);
}

}

The Class BO was written by user B who is stupid,the source code of BO.java is:

class BO{

public void create(Object obj){
try{
Session session=HibernateUtil.openSession();
HibernateUtil.beginTrans();
new DAO().create(session,obj);
HibernateUtil.commitTrans();
}finally{
HibernateUtil.closeSession();
}

}

but not

class BO{

public void create(Object obj){
try{
Session session=HibernateUtil.openSession();
HibernateUtil.beginTrans();
new DAO().create(session,obj);
HibernateUtil.commitTrans();
}
catch(Exception e){
HibernateUtil.rollBackTrans(); // if DAO().create() failed,the trans should be roll back.
}
finally{
HibernateUtil.closeSession();
}

}


I think if User A was forced thrown HibernateException by Hibernate3.x.x from DAO.create(),then the User B would not forgot add the following code.

catch(Exception e){
HibernateUtil.rollBackTrans(); // if DAO().create() failed,the trans should be roll back.
}

checkked exceptions in a *framework* is in almost all cases evil.

we learned from that mistake in Hibrenate 2 and changed it for Hibernate 3 ...the code is *much* cleaner now when you are not *forced* to always catch or throw.

Its always better to check-and-rollback transaction in finally block, rather than aborting it in catch( Exception ) block, because there are Throwables, which doesn't subclass Exception.

I do agree with Hibernate team. If you catch HibernateException, you usually can do nothing meaningful, that will differ from you default exception handling strategy (usually, running in circles and shouting "unexpected internal error"). So, its better to use unchecked exception for such kind of errors.

When we were using Hibernate 2.x with checked HibernateException, there were many places with following code



Which is evil, because is looks like penalty for using framework.

Now these code blocks was gone.

Hi max,

Thanks for your answer.

But i still have some doubts.Would you like tell me where is the cleanness that was brought by UNCHECKED EXCEPTION Hibernate3 in my j2ee project.Though i'm developing with UNCHECKED EXCEPTION Hibernate3,i still must catch HibernateException and throws it in DAO layer for roll back transaction.May be i should change my code in BO layer from

try{
openConnection();
new DAO().create();
commitTrans();
}
catch(Exception e){
rollbackTrans();
}
finally{
closeConnection();
}

to


try{
openConnection();
new DAO().create();
commitTrans();
}
catch(RuntimeException e){ // the line was changed.
rollbackTrans();
}
finally{
closeConnection();
}


Hi,cryozot

Why you said
"Its always better to check-and-rollback transaction in finally block, rather than aborting it in catch( Exception ) block"?

if you don't catch HibernateException and throw a DataException from DAO layer,i think your code in BO layer must be:

try{
openConnection();
new DAO().create();
}
finally{
try{
commitTrans();
}
catch(RuntimeException e)}
rollbackTrans();
}
closeConnection();
}

is it really? please tell me,thank you.

Thanks a lot for your detailed answer.

With checked exception Hibernate2. The code like following:

class DAO {
public void create() throws DataException{
try{
.....
}
catch(HibernateException e){
throw new DataException(e);
}
}
}

With UNCHECKED exception Hibernate3,the code like following:

class DAO{
public void create(){
}
}

The class DAO changed to more clear and it is not required that the class DataException be defined.

is it right?

This code is even more dangerous, because RuntimeException is a subclass of Exception, which is subclass of Throwable. There are other throwables (Errors), which are not Exceptions. If code in your try block will throw Error, transaction won't be aborted.



This code is also wrong. You will commit your transaction even if exception is thrown in try block.

I recomend you to refresh your memories, regarding exception handling in Java, especially how finally block works.

Correct sequence it your case would be something like this:

With checked exception Hibernate2. The code like following:

With UNCHECKED exception Hibernate3,the code like following:

This is correct indeed, and many will be very happy with it, IMHO it has a problem. HibernateException will bubble up to upper layers of your application, where you probably don't want to know anything about Hibernate. That's why I still keep catching and replacing HibernateException with my own exceptions.

It usually not an issue, because "upper layers" of application is neither aware of persistence nor capable to recover from such errors other than write "unexpected error" to log, rollback transaction, and continue. In that case HibernateException and DataException both contains have same meaning, but rethrowing HibernateExcepion makes code more messy.

BTW, if you use lazy-loading, it is impossible anyway to wrap all HibernateException, because they might occur almost anywhere.