|
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
|
