3

catchSonarQube の最新バージョン (4.3.2) を使用すると、try-with-resources ブロックにより、ラインのブランチ カバレッジに誤検知が与えられます。例えば：

public List<String> getLines(String filename) {
    try (InputStream inputStream = getInputStream(filename)){
        return IOUtils.readLines(inputStream);
    } catch (IOException e) { // <<<<<<< REPORTS AS BRANCH COVERAGE 2/8 
        throw new IllegalArgumentException(e);
    }
}

しかし、私の単体テストはすべてのポイントでスローされた例外をカバーし、他のすべての行は 100% のカバレッジを持っています。実際のカバレッジは 100% です。そして、「8」はどこから来たのですか？例外がスローされる可能性がある場所は 8 つではありません。

問題の行に追加// NOSONARしてみたり、すべての行に追加してみたりしましたが、レポートは同じです。

を使用した場合、他の種類の問題は無視された// NOSONARため、ソナーの構成の問題ではありません。

それは、ソナーが、try-with-resources ブロックが生成するバイトコード内の追加の try-catch ブロックを許可していないためだと思います。

ソナーがこの特定の誤検出を正常に無視するようにコードを装飾する方法はありますか?

4

1 に答える 1

7

SonarQube は Java の try-with-resources コンストラクトをサポートしていません。

また、使用時に偽の null チェックの問題が報告されます。

SonarQube は他のツール (PMD/FindBugs など) を使用しており、バイトコード分析を使用しているため、(確かに) これらは誤検知である場合があると言われています。「SonarQube Way」の答えは、結果のバイトコードが適切に処理されるまで、try-with-resources を使用しないことです。

ただし、しっぽを振ることを推奨する正気の開発者はいません。私の提案は、SonarQube プラグインを介して偽陽性としてマークすることですが、この場合のバイトコードの分析が間違っているため、テストカバレッジについては役に立ちません。

SonarQube 自体には何千もの問題があります (彼らは自分のドッグフードを食べます)。

于 2014-07-31T12:02:00.553 に答える