Hibernate code swallows the orginal sql exceptions

Description

It appears that Hibernate code swallows the original sql exceptions which are important for users to determine the real cause of the issue.

The following code snippets are grepped from Hibernate 3.2.4.SP1-CP10:

org.hibernate.loader.Loader: [1]
protected final PreparedStatement prepareQueryStatement(
final QueryParameters queryParameters,
final boolean scroll,
final SessionImplementor session) throws SQLException, HibernateException {
...
catch ( SQLException sqle ) { //line 1582
session.getBatcher().closeQueryStatement( st, null );
throw sqle;
}
catch ( HibernateException he ) {
session.getBatcher().closeQueryStatement( st, null );
throw he;
}

org.hibernate.jdbc.AbstractBatch.java - 3.2.4.SP1-CP10 [2]
public void closeQueryStatement(PreparedStatement ps, ResultSet rs) throws SQLException { //line 201
boolean psStillThere = statementsToClose.remove( ps );
try {
if ( rs != null ) {
if ( resultSetsToClose.remove( rs ) ) {
logCloseResults();
rs.close();
}
}
}
finally {
if ( psStillThere ) {
closeQueryStatement( ps );
}
}
}

The method closeQueryStatement(PreparedStatement ps, ResultSet rs) doesn't have a catch block but throws a SQLException.
This makes the aforementioned prepareQueryStatement method bypass the following call:
throw sqle;
which shows the original sql exception.

Can we change the code in the prepareQueryStatement method to something like?

catch (SQLException sqle) {
try {
session.getBatcher().closeQueryStatement(st, rs);
}
catch (SQLException closeEx) {
//only log the stack trace, maybe we can do something else here.
closeEx.printStackTrace();
}

throw sqle;
}

This way, the original exception would not be swallowed.

[1] http://anonsvn.jboss.org/repos/hibernate/core/tags/JBOSS_EAP_3_2_4_SP1_CP10/src/org/hibernate/loader/Loader.java

[2] http://anonsvn.jboss.org/repos/hibernate/core/tags/JBOSS_EAP_3_2_4_SP1_CP10/src/org/hibernate/jdbc/AbstractBatcher.java

Environment

None

Activity

Show:
Brett Meyer
January 29, 2014, 9:25 PM

Gary, have you tried this on ORM 4.2 or 4.3? That code is very, very different now and no longer involves what you mention.

Brett Meyer
January 30, 2014, 3:38 PM

@Gary Hu, this appears to no longer be an issue – there's nothing to fix upstream. That Loader code now looks like:

session.getTransactionCoordinator().getJdbcCoordinator().release( st ) does not throw a new exception – it catches, logs, and returns early. So, the re-thrown original Exception will still come through from Loader.

Assignee

Unassigned

Reporter

Gary Hu

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure