views:

45

answers:

2

When an org.hibernate.JDBCException occurrs (or a Subtype of this Exception) the sql statement is not visible in the Stacktrace.

For Example if i execute the following SQL statement with hibernate (on an Oracle DB which does not have a table or view 'nonexsiting'):

session.createSQLQuery("select * from nonexisting").list();

i get the following stacktrace:

org.hibernate.exception.SQLGrammarException: could not execute query at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
...

Caused by: java.sql.SQLSyntaxErrorException: ORA-00942: Table or view does not exist
...

The SQL statement is not shown in the stacktrace, however the Exception object has the information stored and can be accessed by exception.getSQL(). It would extremely speed up debugging if this information would be available in the stacktrace too.

Anybody an idea why this information is not available in the stacktrace? Or how to enable the output of this information in the stacktrace?

By the way the hibernate version i used for this example is 3.3.1

A: 

Because that's not how it has been implemented. See HB-1055.

Spring and the classes implementing PersistenceExceptionTranslator might provide something closer to your expectations.

Pascal Thivent
Thanks Pascal for the answer. As far as i unterstand HB-1055 this is about capturing the SQL statement and provide this information via jdbcexception.getSQL(). My question however is more about why this method is not used when printing the stacktrace, as this would be a very valuable information.
hochraldo
@hochraldo: Because Gavin King chose to not put the SQL statement in the `message`, because that's not how he implemented it.
Pascal Thivent
@Pascal: Okay got it. Still would be interesting to know why Gavin decided not to put this information in the stacktrace...
hochraldo
A: 

I assume that it could be a security issue. If you add the sql statement to the stack trace, it might be published to a user and so give him information about your table names and columns. If your application is vulnerable to sql injection, this would be a really big benefit for intruders.

Gernot
@Gernot: Never considered this, but this seems evident to me. Thanks for this insight.
hochraldo