Affects: 4.2.4

The JdbcTemplate class allows statement warnings to be processed, see the JdbcTemplate# handleWarnings(Statement) method. However, the warnings are only processed on successful execution of the statement, though warnings may be generated even if the statement fails.

See the methods: execute(StatementCallback) execute(PreparedStatementCreator , PreparedStatementCallback) execute(CallableStatementCreator , CallableStatementCallback )

All these should probably call handleWarnings in their catch block before closing the statement.

Comment From: gabbagnale

I think that might be enough move the call to handleWarnings inside finally instead that in the try. or double it inside the catch

Comment From: jMediaConverter

I think that might be enough move the call to handleWarnings inside finally instead that in the try. or double it inside the catch

That's right.

Comment From: jhoeller

There are only really two modes of operation for handleWarnings: either log a debug message when ignoreWarnings=true (the default), or otherwise throw a SQLWarningException. This makes sense for successful statements but I wonder what kind of behavior you'd expect for failed statements where a primary exception is about to be thrown. Overriding such a primary exception with a SQLWarningException is awkward, so we can't simply call handleWarnings from the catch block there. We could only really call it with a nested catch (SQLWarningException) block that logs the warning, or with a new variant of handleWarnings which always logs a warn message when ignoreWarnings=false (but never throws an exception).

Comment From: jMediaConverter

Let me explain my exact use case. I am calling a stored procedure using JdbcTemplate, that stored procedure creates multiple warnings and then it fails for whatever reason (SqlExceptionis thrown). In this scenario there is no way for me to access/log the warnings that the stored procedure generated because handleWarningsis called only on successful execution of the stored procedure. It could potentially be called in the exception block or in the finally. In my project I extended the JdbcTemplateand overrode the execute methods and created my custom warnings handling mechanism. However, I do think it would be nice for JdbcTemplateto do this out of the box. I do see your point about the second mode of operation of handleWarnings with SQLWarningException hiding the primary exception. Maybe SqlWarningException could take the primary exception as the cause.

Comment From: jhoeller

It looks like we can add the SQLWarning from the SQLWarningException to the primary SQLException as a chained exception, through the JDBC 4 SQLException.setNextException method. So doing that in case of ignoreWarnings=false seems like a sensible arrangement, whereas the default ignoreWarnings=true behavior would be a no-op (just potentially with debug logging). In any case, you'd get the handleWarnings(Statement) invocation in the exception case as well, so any custom logic in an overridden method there would get invoked.

Comment From: jMediaConverter

Sounds like a good plan. Thanks.

Comment From: jhoeller

Thanks for quick turnaround! Rolling this into 6.0.11 and backporting it to 5.3.29, both to be released on Thursday.