Bug #70835 Incorrect SQLException subclass thrown for query interrupted

Description:
In SQLError.createSQLException(), checks are done to return appropriate JDBC4-typed SQLException subclasses:

} else if (sqlState.startsWith("40")) {
    if (!Util.isJdbc4()) {
        sqlEx = new MySQLTransactionRollbackException(message,
                sqlState, vendorErrorCode);
    } else {
        sqlEx = (SQLException) Util
            .getInstance(
                    "com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException",
                    new Class[] { String.class, String.class,
                            Integer.TYPE  }, new Object[] {
                            message, sqlState,
                            Integer.valueOf(vendorErrorCode) }, interceptor);
    }
}
...

However, this is not done for query interruption exceptions:

} else if (sqlState.startsWith("70100")) {
    sqlEx = new MySQLQueryInterruptedException(message, sqlState, vendorErrorCode);
}
the non-JDBC4 MySQLNonTransientException, which in turn extends SQLException.  For JDBC4 deployments, the thrown Exception should subclass com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException.

How to repeat:
1.  Create two Connection objects in a JRE of 1.6 or higher.
2.  Issue SELECT SLEEP(500) in one Connection.
3.  Issue KILL QUERY in the second Connection, targeting the first.
4.  Test the resulting SQLException from the first Connection to see if it subclasses java.sql.SQLNonTransientConnectionException.

Suggested fix:
Create a new JDBC4-specific version of MySQLQueryInterruptedException which subclasses MySQLNonTransientException.

Posted by developer:
 
Fix pushed in revision 1267.

Added the following entry to the Connector/J 5.1.28 changelog:

"An incorrect SQLException subclass was thrown during a query interruption. This fix creates a new, JDBC4-specific version of MySQLQueryInterruptedException, which subclasses MySQLNonTransientException."