Redundant-Throws-Declaration-Check False positive on custom SecurityException

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

When extending Exception and choosing a clashing Name like SecurityException, SonarQube does not recognize that it’s not Java’s java.lang.SecurityException. Therefore, it’s complaining about a superfluous RuntimeException declaration:

Remove the declaration of thrown exception 'java.lang.SecurityException' which is a runtime exception.

Note:
This only occurs on SonarQube Server (or probably in the Scanner), the SonarLint plugin for IntelliJ IDEA does not have this issue.

versions used

  • SonarQube: 7.6 (build 21501)
  • Scanner: 3.3.0.1492
  • language analyzer: SonarJava 5.11 (build 17289)

code sample

package myexceptions;
public class SecurityException extends Exception {
    public SecurityException(String message) {
        super(message);
    }
    public SecurityException(Throwable throwable) {
        super(throwable);
    }
    public SecurityException(String message, Throwable throwable) {
        super(message, throwable);
    }
}

import myexceptions.SecurityException;
public class A {
    public void anyMethod() throws SecurityException {} // complaining here
}
2

Hi,

You are most likely hitting an issue about classpath order : The related ticket seems to be : https://jira.sonarsource.com/browse/SONARJAVA-3056 and https://jira.sonarsource.com/browse/SONARJAVA-2957

How are you running the scanners ? using maven or gradle ? it not, can you provide the configuration used for sonar.java.libraries and sonar.java.binaries ?

3

Hi Nicolas,

First of all, a big thank you for your response. This is an interesting hint, it really looks like this parent first strategy could be the issue!

We are running the scanner from the Jenkinsfile, the stage looks like this:

stage('Code analysis') {
    withSonarQubeEnv('SonarQube Code Quality Server') {
        def scannerHome = tool 'SonarQube Scanner'
        sh "${scannerHome}/bin/sonar-scanner -Dsonar.branch.name=${env.BRANCH_NAME} -Dsonar.projectVersion=${version}"
    }
}

The according sonar-project.properties:

sonar.sourceEncoding=UTF-8
sonar.java.source=1.8
sonar.java.binaries=target
sonar.java.libraries=\
  /var/lib/jenkins/.ivy2/cache/**/*.jar,\
  /var/lib/jenkins/.m2/repository/**/*.jar
sonar.java.test.libraries=\
  /var/lib/jenkins/.ivy2/cache/**/*.jar,\
  /var/lib/jenkins/.m2/repository/**/*.jar

sonar.modules=cluster,core,frontend,js

# Cluster
cluster.sonar.sources=src/main

# Core
core.sonar.sources=src/main
core.sonar.java.libraries=lib/*.jar
core.sonar.tests=src/test

# Frontend
frontend.sonar.sources=app
frontend.sonar.tests=test

# JS
js.sonar.projectBaseDir=static/main/assets/js
js.sonar.sources=src

Edit: Forgot to mention our build tool: it is sbt (maybe this matters).

4

Thanks for sharing this.
There might be this issue at play but there might also be something else at play.
just to be sure, where are located the classes in the target directory ?
I believe the sonar.java.binaries property should point to the output dir of SBT .class
So something like : sonar.java.binaries=target/scala-2.12/classes should get the compiled classes properly loaded and might help to solve your issue.

5

This actually seems to solve the issue about those false positives, thank you a lot for figuring this out!

But what I’ve seen after applying this change is that we’ve got some more warnings about classes not being found during analysis:

Before

WARN: Classes not found during the analysis : [org.slf4j.Logger]

After

WARN: Classes not found during the analysis : [akka.actor.AbstractActor, akka.actor.Actor, akka.actor.ActorContext, akka.actor.ActorLogging, akka.actor.ActorRef, akka.actor.ActorSystem, akka.actor.Cancellable, akka.actor.SupervisorStrategy, akka.actor.SupervisorStrategyConfigurator, akka.actor.Terminated, akka.actor.UntypedActor, akka.cluster.Cluster, akka.cluster.MemberStatus, akka.event.LoggingAdapter, be.objectify.deadbolt.core.models.Permission, be.objectify.deadbolt.core.models.Role, be.objectify.deadbolt.core.models.Subject, com.fasterxml.jackson.databind.node.ObjectNode, com.google.common.base.Equivalence, com.google.common.base.Function, com.google.common.base.Supplier, com.google.common.cache.Cache, com.google.common.cache.LoadingCache, com.google.common.collect.ImmutableList, com.google.common.collect.ImmutableMap, com.google.common.collect.ImmutableMultimap, com.google.common.collect.Multimap, com.google.common.hash.HashCode, com.google.common.hash.HashFunction, com.google.common.io.ByteSink, com.google.common.io.ByteSource, ...]

Because the analysis seems to be more precise in general as well, I could live with that. But I am still a little anxious about this warning… Do you another idea?

6

This is another issue and this means that those classes that you are depending upon (maybe transitively) could not be found in the classpath specified with sonar.java.binaries and sonar.java.libraries.
Check the sonarqube documentation in order to have a proper configuration of this classpath.

7

This was actually the case. Now I just have the issue mentioned in [1], but this doesn’t bother me too much.

Thank you a lot for your support!

[1] https://groups.google.com/forum/#!searchin/sonarqube/class$20not$20found|sort:relevance/sonarqube/6KCcSDcnHoE/cAM6TnmlAQAJ