We are testing the introduction of some SonarQube rules in our codebase that have to do with flagging openings of connections that are not closed in catch or finally blocks, and missed opportunities to use try-with-resources. The rules flag the following code block:
final Connection connection = jThalesDs.getConnection();
final PreparedStatement pstmt = connection.prepareStatement(String.format(GET_SERVER_IDS_AND_TEST_LOGINS, dbSchemaProps.getOracleJThales()));
try {
// Some calls that may or may not throw something
} catch(Throwable exc){
// Closing the resources and re-throwing the exception
pstmt.close();
connection.close();
throw exc;
}
// Whoops, forgot to include a finally block where we close the connections.
As can be verified through this screenshot:
In the very same file, however, a more serious violation of the same rule is not being flagged as either a bug or a code smell, and SonarQube instead focuses on the genericity of the class being thrown (a RuntimeException):
final Connection conn = jThalesDs.getConnection();
try {
// More calls that may or may not throw
}
catch (Throwable ex) {
// Whoops, forgot to close the connection if not null!
throw new RuntimeException(TEST_LOGINS_DB_ERROR, ex);
}
So, to recap. In the same file, I have a bug and code smell that is being caught by SonarQube, and it concerns the fact that I am not closing resources in a finally block. However, in an even more grievous violation of the same rules, in the same file, those rules are not triggered.
What could be going on here? FWIW, we are running the latest LTS, 9.9.2.

