S1854 FP - Remove this useless assignment to local variable

Clean Code Report False-positive / False-negative...
1

Make sure to read this post before raising a thread here:

Then tell us:

Java
SonarQube v10.5.1

Indicates useless assignment to ‘METHOD’

private static void rollbackOrCommit(DBConnection theDB)
{
    final String METHOD = CLASS + ".rollbackOrCommit";

    if (theDB != null)
    {
		if (theDB.doRollbackOnError)
		{
			theDB.rollback();
		}
		else
		{
			try
			{
				theDB.commit();
			}
			catch (SQLException ex)
			{
				Log.log(1, METHOD, "dberror", Log.ERROR, "", "", "");
				theDB.rollback();
			}
        }
    }
}
2

Hey there.

We know that sometimes this rule raises false-positives when the “semantic” is incomplete: SONARJAVA-4960

How do you execute your analysis (which scanner do you use? the SonarScanner CLI, the SonarScanner for Maven? Gradle?)

Do you receive any warnings during the analysis?

3

I don’t know what ‘semantic’ is incomplete refers to. We are getting about 90 of these false positives.

The SonarQube is being executed from a Jenkins build

I took some screen capture below

image001.png2641×1808 491 KB

image002.png
image002.png2641×1808 447 KB

4

How about you share how your Jenkins build is configured?

5

The code all compiles.

6

They all seem to deal with catching SQLException and the variable is only being used in the catch block.

7

I have a attached the groovy file. I don’t really know much about the Jenkins build.

(Attachment MCS_CommitBuild.groovy is missing)

8

Zip file blocked on our side. Here is partial screen capture.

image001.png2140×1746 162 KB

9

Hey again.

Indeed, it looks like you’re running the SonarScanner CLI, which isn’t the recommended way (unless your normal build tool is an ant, in which case it’s the only way).

This is because the SonarScanner CLI requires a lot of manual configuration to perform an accurate analysis of Java, specifically the bytecode (the “semantic” I was referring to earlier)

I’m not sure what build tool is underneath your make commands are hiding. Can you tell me more about how your Java code is compiled?

10

Yes, we are using ant as the build tool, but don’t really understand how the build tool impacts the sonar analysis since the source and byte code generated are not really dependent on the build tool that is utilized. Java is still responsible for generating the byte code and not the build tool.

11

Yes, but how that bytecode makes its way to the scanner to help analysis is build-tool dependent (and for Maven and Gradle, we can pick up those paths automatically).

We have documented a migration path from the SonarScanner for Ant to the SonarScanner CLI. You weren’t ever using the SonarScanner for Ant, but the general advice (add sonar.java.* to a sonar-project.properties file) still applies.

Once the proper bytecode is being read into your analysis, these FPs on S1854 should go away.

12

We already have the following in our properties file:

sonar.sources=src/classmcs,src/legacy

sonar.java.binaries=classes/legacy,classes/classmcs

sonar.java.libraries=serverLib,springbootLib,clientLib,smartFactoryLib,3rdParty

Is there something else we need to add.

13

Ideally, no, if all that information is complete and correct.

I have a feeling to learn more, we’d need to see the complete output of the sonar-scanner at DEBUG level (sonar-scanner -X)