Checkstyle сообщает об ошибке LocalFinalVariableNameCheck для параметра catch-exception

У меня странная проблема, и я не уверен, что это проблема между двумя ушами или проблема в стиле чекстайл. Запустив checkstyle 6.2, мы получим и jenkins, и затмение:

LocalFinalVariableNameCheck, Priority: Normal 

Name 'pEx' must match pattern '^l[A-Z][a-zA-Z0-9]*$'.

и это код

...
} catch (final XPathExpressionException pEx) {
   throw new ConfigurationException(pEx);
}

Почему checkstyle определяет блок catch как локальную переменную, а не как параметр?

Источник

3 ответа

Решение

С помощью Бориса я нашел решение. Это изменение, которое было включено в checkstyle 5.7, как это выглядит

    <module name="LocalFinalVariableName">
        <!-- checkstyle changed to pass exception checks to local vars?!? in version 5.7 -->
        <!-- catch blocks have params => use a different local var -->
        <property name="format" value="^p[a-zA-Z0-9]*$" />
        <property name="tokens" value="PARAMETER_DEF" />
    </module>
    <module name="LocalFinalVariableName">
        <property name="format" value="^l[A-Z][a-zA-Z0-9]*$" />
        <property name="tokens" value="VARIABLE_DEF" />
    </module>
    <module name="LocalVariableName">
        <!-- checkstyle changed to pass exception checks to local vars?!? in version 5.7 -->
        <!-- catch blocks have params => use a different local var -->
        <property name="format" value="^p[a-zA-Z0-9]*$" />
        <property name="tokens" value="PARAMETER_DEF" />
    </module>
    <module name="LocalVariableName">
        <property name="format" value="^l[A-Z][a-zA-Z0-9]*$" />
        <property name="tokens" value="VARIABLE_DEF" />
    </module>
Источник

Как указывает @Dongqing, pEx действительно является локальной переменной, поэтому проверка применяется здесь.

Одно замечание: по умолчанию для этого правила ^[a-z][a-zA-Z0-9]*$ как указано в документации по checkstyle (последняя версия инструмента). Шаблон, который вы, вероятно, настроили в соответствии с местным стандартом ^l[A-Z][a-zA-Z0-9]*$, Поэтому, прежде чем удалять нарушение, вы, вероятно, должны убедиться, что шаблон именования действительно в порядке (зачем определять пользовательское правило, если оно не подходит?).

Если вы действительно хотите избавиться от этого нарушения, Checkstyle предоставляет различные способы подавления предупреждений. Вы можете:

  • Используйте подавляющий XML-файл, который позволяет запретить конкретное правило в конкретном файле для заданного диапазона строк (или даже диапазона столбцов). Таким образом, вам не нужно изменять код, но вам нужно поддерживать отдельный файл со всеми вашими подавлениями.
  • Используйте комментарии или аннотации, чтобы отключить предупреждения, добавив комментарий или аннотацию (например, @SuppressWarnings) прямо в коде, где ложное срабатывание есть. Это тоже нужно настроить. Смотрите ссылку выше для более подробной информации и примеров.

РЕДАКТИРОВАТЬ: Это правило Checkstyle также позволяет вам настроить шаблон для объявления переменных или предложений catch. Следующая конфигурация должна работать для вас:

<module name="LocalVariableName">
    <property name="format" value="^[a-zA-Z0-9]*$"/>
    <property name="tokens" value="PARAMETER_DEF"/>
</module>

Здесь вы указываете очень допустимую схему нарушений только в предложениях catch. Объявление переменной не должно быть затронуто и все же проверяться на исходный шаблон.

Источник

try {} catch (){} это оператор, а не вызов метода. так что pEx это локальная переменная, а не параметр

Источник
Другие вопросы по тегам