• Post Reply Bookmark Topic Watch Topic
  • New Topic

getWarnings() and clearWarnings() on a closed resource (K&B7, chapter 15, page 903)  RSS feed

 
J Deckarm
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chapter 15, page 903
Description of the methods getWarnings() and clearWarnings() states "A SQLException is thrown if the method is called on a closed object."
=> It seems this is dependent on the type of the closed object. For me only stmt.close() followed by stmt.***Warnings() seem to produce "SQLRecoverableException: Closed Statement". But e.g. conn.close() followed by conn.***Warnings(), or stmt.close() followed by rs.***Warnings() do not seem to produce any exception

(This post originated in the K&B7 errata thread)
 
Roel De Nijs
Sheriff
Posts: 11333
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J Deckarm wrote:=> It seems this is dependent on the type of the closed object. For me only stmt.close() followed by stmt.***Warnings() seem to produce "SQLRecoverableException: Closed Statement". But e.g. conn.close() followed by conn.***Warnings(), or stmt.close() followed by rs.***Warnings() do not seem to produce any exception

First of all, I checked the javadoc for these methods on all 3 objects: Connection, Statement, and ResultSet.

Here's a snippet of the javadoc of the Connection interface for both the clearWarnings() and getWarnings() methods:
Java 7 API Specification, Connection wrote:void clearWarnings() throws SQLException
Throws:
SQLException - SQLException if a database access error occurs or this method is called on a closed connection
Java 7 API Specification, Connection wrote:SQLWarning getWarnings() throws SQLException
Throws:
SQLException - if a database access error occurs or this method is called on a closed connection
If you look at the Statement and ResultSet interfaces you can read similar descriptions for both the clearWarnings() and getWarnings() methods. So I understand that's what a study guide mentions in its text, because that's how those methods should behave and that's what you need to know for the exam.

Then I had a go as well and used MySql (mysql-connector-java-5.1.36). My first attempt was on a closed result setOutput:
SQLException: Operation not allowed after ResultSet closed
SQLState: S1000
VendorError: 0


Second attempt on a closed statementOutput:
SQLException: No operations allowed after statement closed.
SQLState: S1009
VendorError: 0


Finally, the third attempt on a closed connectionBut this code didn't throw a SQLException. So I got a little but curious and decided to look at the implementation of the getWarnings() method of the Connection interface. I was a bit surprised when I opened the com.mysql.jdbc.ConnectionImpl and noticed this getWarnings() implementationIt just returns null. So that explains pretty well why I didn't get a SQLException, although I should have got one according to the API

Hope it helps!
Kind regards,
Roel
 
Roel De Nijs
Sheriff
Posts: 11333
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the study guide's point of view, it's reasonable (and even recommended) to explain what's mentioned in the javadoc for a method, because that's probably what you will be tested about on the actual exam Although not every driver seems to meet the contract defined by the JDBC interfaces, the javadoc of the clearWarnings() and getWarnings() methods of Connection, Statement, and ResultSet clearly state an SQLException is thrown if the method is called on a closed object (connection, statement, and/or result set). So I think there's no need to add this one to the errata overview.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!