No Exception for ResultSet TYPE_FORWARD_ONLY

[Rahul Shinde]

Here is my code example. I am expecting an exception that indicates that the ResultSet is TYPE_FORWARD_ONLY but I get none. I am using MySQL DB with Type 4 Driver.
Right now I get the contents of the contacts table printed twice with no exceptions.
JavaDoc says

Statement createStatement() throws SQLException
Result sets created using the returned Statement object will by default be type TYPE_FORWARD_ONLY and have a concurrency level of CONCUR_READ_ONLY.

What am I missing here?

  void selectDBTwice() {
    String query = "select * from contacts";
    System.out.println("Selecting DB with query: " + query);
    try (Connection conn = getConnection(); // a Valid connection
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery(query);) {
      while (rs.next()) {
        printRow(rs);
      }
      rs.beforeFirst();
      while (rs.next()) {
        printRow(rs);
      }
      
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }

  static void printRow(ResultSet rs) throws SQLException {
    String data = "Id=" + rs.getInt("id")
        + " firstName=" + rs.getString("firstName")
        + " lastName=" + rs.getString("lastName") 
        + " phoneNo=" + rs.getString("phoneno");
    System.out.println("Row: " + data);
  }
  

[Paul Clapham]

Have you examined the ResultSet to see what its type actually is? I haven't looked, but I expect there must be a method which you can call to find out.

[Rahul Shinde]

I added the getType() method on the ResultSet to print that.
It says "Type = 1003"

ResultSet.java says

int TYPE_FORWARD_ONLY = 1003;

[Martin Vashko]

I'd say that the resultset type determines the minimum capabilities of the resultset. In this case, the authors of the JDBC driver probably saved themselves some work by not implementing the forward only type, and used the more capable one instead. In correctly coded applications this shouldn't lead to problems. You might get a problem if you tested your application with a different JDBC driver than the one actually used in production (by not catching this bug in test and having it appear only in production, for example) - however, it is always advisable to match the test environment as closely to the production environment as possible.