Sonarqube ложно-положительный для "Использовать try-with-resources или закрыть этот" ResultSet "в" наконец "предложении" - PullRequest
0 голосов
/ 26 октября 2018

Sonarqube продолжает помечать код этой проблемой, что, на мой взгляд, является ложным срабатыванием.Код выглядит следующим образом:

try(PreparedStatement st=con.prepareStatement(myQuery)){
    st.setInt(1, myValue);
    ...
    ResultSet rs = st.executeQuery();
    ...
}

Если я не ошибаюсь, PreparedStatement реализует Closeable и, закрывая себя, также закрывает базовый ResultSet.

Такое поведение предотвратит ResultSetиз-за того, что анализ Sonarqube помечает это как критическую ошибку.

Я ошибаюсь?Любой способ заставить Sonarqube игнорировать это правило при таких обстоятельствах ?

Протестировано в Sonarqube 6.7.3 и JDK 8.

Из ResultSet javadoc:

Объект ResultSet автоматически закрывается, когда объект Statement, сгенерировавший его, закрывается, повторно выполняется или используется для получения следующего результата из последовательности нескольких результатов.

Ответы [ 3 ]

0 голосов
/ 26 октября 2018

Вероятно, неразумно ожидать, что анализаторы кода узнают о таких вещах. Может ли инструмент знать всю -дополнительную семантику всех Closeables во всех библиотеках, написанных где-либо в любое время?

Доку действительно упоминает, что «текущий ResultSet, если таковой имеется, также закрыт».

Обратите внимание на «текущий». Что произойдет, если у вас два разных вызова executeQuery ()? Это потерпит неудачу из-за плохого статуса или чего-то подобного? Будут ли два разных объекта ResultSet, оба незамкнутых, и один из них теперь не будет ссылаться?

(Примечание: два разных вызова executeQuery () могут звучать совершенно безумно, но помните, что «кодеры могут делать все что угодно», и это даже очень причина , почему такие инструменты, как SonarQube написаны в первую очередь.)

Я не говорю, что это совершенно непобедимо, но мне не кажется странным, что инструмент анализа просто видит, что вы получаете закрываемый объект, а не закрываете его и просто жалуетесь на него.

0 голосов
/ 27 октября 2018

Действительно, это ложный положительный результат.Об этом уже сообщалось, и есть открытый тикет, чтобы исправить это https://jira.sonarsource.com/browse/SONARJAVA-2060

Вы можете пометить проблему как ложноположительную в пользовательском интерфейсе SonarQube или добавить комментарий // NOSONAR в строку, где возникла проблемаигнорировать это.

0 голосов
/ 26 октября 2018

В файле pom.xml нет файла свойств или какой-либо конфигурации

Пожалуйста, ознакомьтесь с этой документацией , вы можете создать файл sonar-project.properties в корневой директории проекта и установить множество различных свойств, которые влияют на ваш анализ. Одним из них является sonar.java.source, который позволяет вам конкретную конкретную версию Java. ( подробности )

Любой способ заставить Sonarqube игнорировать это правило при этом обстоятельства?

У меня была ситуация, когда механизм sonarqube помечал блок кода как проблему, но с точки зрения разработчика это не так, поэтому в этом случае его можно пометить как ложноположительный. Чтобы установить правила, которые разрешают / запрещают помечать проблемы в определенных файлах, пожалуйста, обратитесь к этому sonarqube документация .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...