Вчера всё работало, а сегодня не работает / Код не работает как задумано
В чем заключается процесс отладки? Что это такое?
Процесс отладки состоит в том, что мы останавливаем выполнения скрипта в любом месте, смотрим, что находится в переменных, в функциях, анализируем и переходим в другие места; ищем те места, где поведение отклоняется от правильного.
Заметка: Отладка производится как правило в IDE (Интегрированная среда разработки). Что это такое можно чуть подробнее ознакомиться в вопросе
Какие есть способы предупреждения ошибок, их нахождения и устранения?
В данном случае будет рассмотрен пример с Intellij IDEA, но отладить код можно и в любой другой IDE.
Подготовка
Достаточно иметь в наличии IDE, например Intellij IDEA
Запуск
Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint – брейкпойнт). Это то место, где отладчик автоматически остановит выполнение Java, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.
В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет метод, выполнение “заморозится” на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку в UI, передача POST запроса с данными и прочие другие действия)
Процесс
Для самого процесса используются элементы управления (см. изображение выше, выделено зеленым прямоугольником) и немного из дополнительно (см. изображение выше, выделено оранжевым прямоугольником)
Show Execution Point (Alt+F10) — переносит в файл и текущую линию отлаживаемого скрипта. Например если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка 🙂
Step Over (F8) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.
Step Into (F7) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.
Step Out (Shift+F8) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.
Rerun (Ctrl+F5) — Перезапустить отладку
Resume Program(F9) — Продолжает выполнения скрипта с текущего момента. Если больше нет других точек останова, то отладка заканчивается и скрипт продолжает работу. В ином случае работа прерывается на следующей точке останова.
Stop (Ctrl+F2) — Завершить отладку
View Breakpoints (Ctrl+Shift+F8) — Посмотреть все установленные брейкпойнты
Mute Breakpoints — Отключить брейкпойнты.
Итак, в текущем коде видно значение входного параметра:
Если теперь нажмем F8, то попадем внутрь цикла for и нажимая теперь F8 пока не окончится цикл, можно будет наблюдать на каждой итерации, как значение num и sum постоянно изменяются. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.
Дальнейшие нажатия F8 переместит линию кода на строки 31, 32 и, наконец, 36.
Дополнительно
Если нажать на View Breakpoints в левой панели, то можно не только посмотреть все брейкпойнты, но в появившемся окно можно еще более тонко настроить условие, при котором на данной отметке надо остановиться. В методе выше, например, нужно остановиться только когда sum превысит значение 20.
Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).
Больше информации об отладке можно посмотреть в http://learn.javajoy.net/debug-intellij-idea, а также в официальной документации к IDE
Простыми словами, трассировка стека – это список методов, которые были вызваны до момента, когда в приложении произошло исключение.
В указанном примере мы можем точно определить, когда именно произошло исключение. Рассмотрим трассировку стека:
Exception in thread “main” java.lang. NullPointerException
at com.example.myproject. Book.getTitle(Book.java:16)
at com.example.myproject. Author.getBookTitles(Author.java:25)
at com.example.myproject. Bootstrap.main(Bootstrap.java:14)
Для отладки этого фрагмента открываем Book.java и смотрим, что находится на строке 16:
Это означает то, что в приведенном фрагменте кода какая-то переменная (вероятно, title) имеет значение null.
Пример цепочки исключений
Иногда приложения перехватывают исключение и выбрасывают его в виде другого исключения. Обычно это выглядит так:
Трассировка в этом случае может иметь следующий вид:
В этом случае разница состоит в атрибуте “Caused by” («Чем вызвано»). Иногда исключения могут иметь несколько секций “Caused by”. Обычно необходимо найти исходную причину, которой оказывается в самой последней (нижней) секции “Caused by” трассировки. В нашем случае, это:
Caused by: java.lang. NullPointerException <– root cause
at com.example.myproject. Book.getId(Book.java:22) <– important line
Аналогично, при подобном исключении необходимо обратиться к строке 22 книги Book.java, чтобы узнать, что вызвало данное исключение – NullPointerException.
Еще один пугающий пример с библиотечным кодом
Как правило, трассировка имеет гораздо более сложный вид, чем в рассмотренных выше случаях. Приведу пример (длинная трассировка, демонстрирующая несколько уровней цепочек исключений):
В этом примере приведен далеко не полный стек вызовов. Что вызывает здесь наибольший интерес, так это поиск функций из нашего кода – из пакета com.example.myproject. В предыдущем примере мы сначала хотели отыскать «первопричину», а именно:
Caused by: java.sql. SQLException
Однако все вызовы методов в данном случае относятся к библиотечному коду. Поэтому мы перейдем к предыдущей секции «Caused by» и найдем первый вызов метода из нашего кода, а именно:
Аналогично предыдущим примерам, необходимо обратить внимание на MyEntityService.java, строка 59: именно здесь появилась ошибка (в данном случае ситуация довольно очевидная, так как об ошибке сообщает SQLException, но в этом вопросе мы рассматриваем именно процедуру отладки с помощью трассировки).
Ошибки времени разработки легко обнаружить, потому что NetBeans обычно подчеркивает их. Если ошибка не позволит запустить программу, NetBeans подчеркнет ее красным.
Логические ошибки – это те, которые вы делаете как программист. Программа запустится, но, поскольку вы сделали что-то не так в коде, есть большая вероятность, что произойдет сбой. Вскоре вы увидите примеры ошибок во время выполнения. Вы также узнаете, как с ними справляться. Но сначала немного о том, как Java обрабатывает ошибки.
В качестве примера обработки исключений в Java создайте новое консольное приложение. Назовите его как вам угодно. В коде метода Main введите следующее:
a
b
c a b
outprintlnc
show_error
outprintlnshow_errorgetMessage
Если что-то пойдет не так, у нас есть «план B». В круглых скобках мы написали это:
Exception – это тип исключения, которое мы используем. В нашем случае это Exception объекта ошибки. Это тип исключения «поймать все» (catch all) и не самая лучшая практика программирования. Мы заменим Exception для обработки наших исключений Java на определенный тип в конце статьи.
После типа исключения идет имя переменной. Мы назвали нашу ошибку show_error, но вы можете называть свои ошибки как вам угодно.
В фигурных скобках catch у нас есть оператор println. Но главное, что мы поставили в круглых скобках println:
getMessage – это метод, доступный объектам Exception. Как следует из его названия, он получает сообщение об ошибке, связанное с исключением.
Запустите программу и протестируйте ее. Ваш код должен выглядеть примерно так:
ErrorsHand
main args
a
b
c a b
outprintlnc
show_error
outprintlnshow_errorgetMessage
И в окне «Вывод» должно отображаться следующее:
Измените в коде на это:
a
b
c a b
Остальная часть кода может остаться прежней. Запустите эту программу и протестируйте ее.
Опять же, сообщение об ошибке будет отображаться в окне вывода:
На этот раз Java останавливает программу, потому что результатом будет бесконечно большое число (Infinity).
Ошибки, связанные с числами, на самом деле не должны проходить обработку типом исключения «catch all». Существует определенный тип для такой обработки, называемый ArithmeticException. Удалите слово Exception в круглых скобках вашего блока catch. Замените его на ArithmeticException. Теперь запустите программу снова.
Вы не должны найти никакой разницы в сообщении об ошибке, отображаемом в окне вывода. Но вы используете правильную практику программирования, сужая тип ожидаемой ошибки.
Типы исключений
Исключения могут быть контролируемыми и неконтролируемыми. Разница состоит в следующем. Если метод может выбрасывать (генерировать) контролируемое исключение, и обработка этого исключения в методе не предусмотрена, то в сигнатуре этого метода необходимо указать ключевое слово throws и тип контролируемого исключения.
Самые распространенные неконтролируемые исключения Java
В следующем уроке вы узнаете, что такое отладка в Java.
How to use the free code checker
Copy and paste your Java code into the editor.
Select your language from the dropdown.
Click the Check code button.
Use the results to improve your Java code.
Get code security right from your IDE
This free code checker can find critical vulnerabilities and security issues with a click. To take your application security to the next level, we recommend using Snyk Code for free right from your IDE.
Human-in-the-Loop JavaScript Code Checker
Snyk Code is an expert-curated, AI-powered JavaScript code checker that analyzes your code for security issues, providing actionable advice directly from your IDE to help you fix vulnerabilities quickly.
Scan and fix source code in minutes.
Fix vulns with dev friendly remediation.
Integrated in IDE
Find vulns early to save time & money.
Integrates into existing workflow.
More than syntax errors
Comprehensive semantic analysis.
Modern ML directed by security experts.
Automatically scan every PR and repo.
CI/CD security gate
Integrate scans into the build process.
Frequently asked questions
SonarJava — это статический анализатор кода для Java от SonarSource. В перечень его функций входит:
Запускать анализ можно как в различных IDE (через плагин SonarLint), так и отдельно в SonarQube.
SonarLint умеет работать бок о бок со встроенным анализатором кода IntelliJ IDEA. Если навести курсор на выделенный фрагмент кода, часто можно увидеть предупреждения от обоих анализаторов:
Конечно, вы можете просмотреть предупреждение в отдельном окне:
В целом, возможность запускать SonarJava по-разному делает его привлекательным. Это дает разработчикам свободу выбора инструмента при написании кода.
FindBugs / SpotBugs
К сожалению, FindBugs уже давно не обновляется, последний стабильный релиз был выпущен еще в 2015 году. Но мы по-прежнему его помним и используем, так как это, пожалуй, самый известный бесплатный статический анализатор кода Java. Если вы спросите Java-разработчика о статическом анализе, то он, вероятно, сразу же вспомнит FindBugs.
Анализатор с открытым исходным кодом SpotBugs стал логическим продолжением заброшенного FindBugs. В нем присутствуют все преимущества и недостатки FindBugs. Время покажет, хорошо это или плохо. А пока сообщество анализаторов его активно развивает. Основные возможности SpotBugs:
Для поиска подозрительного кода используются все те же методологии: сопоставление с образцом и анализ потока данных. Анализатор обнаруживает различные типы ошибок, которые связаны с многопоточностью, производительностью, уязвимостями, обфускацией кода и так далее.
В IntelliJ IDEA окно предупреждений выглядит так:
Предупреждения можно сгруппировать по категориям, классам, каталогам и уровню достоверности. Вы можете одновременно просматривать предупреждения и документацию по любому диагностическому правилу.
Анализ запускается вручную. После анализа все проблемные фрагменты кода выделяются вместе с другими предупреждениями от IntelliJ IDEA и SonarLint. Однако есть проблема. Вы должны перезапустить анализ, чтобы обновить предупреждения в соответствии с внесенными вами изменениями файла. Также существует множество рекомендательных предупреждений, поэтому перед активным использованием необходимо настроить анализатор.
PVS-Studio
PVS-Studio основан на библиотеке с открытым исходным кодом Spoon. Он получает исходный код в качестве входных данных и строит хорошо спроектированную модель AST с семантической информацией. На основе этой модели в анализаторе используются такие современные методики, как:
На данный момент анализатор использует более 105 диагностических правил, выявляющих на различные недостатки кода. Они включают в себя исправление опечаток, переименование null-ссылок, недостижимый код, индекс массива вне границ, нарушение использования договора метода и другие ошибки. Вы можете узнать все возможности диагностических правил здесь.
Основные функции PVS-Studio:
PMD
PMD — это статический анализатор с открытым исходным кодом. Он выявляет типичные ошибки разработки: неиспользуемые переменные, пустые блоки, создание ненужных объектов и другие проблемы.
В качестве входных данных анализатор использует исходный код. В данный момент PMD анализирует один исходный файл в течение одного процесса работы, что накладывает ограничения на полноту анализа. Авторы PMD советуют собирать проект перед анализом. Это позволяет извлекать информацию о типах, используемых в анализируемом коде.
Основные функции PMD:
Если мы посмотрим на все диагностические правила, то PMD больше ориентирован на решение проблем стиля кодирования и обнаружение очевидных ошибок. Правила диагностики могут противоречить друг другу, поэтому их необходимо настроить перед использованием анализатора.
Вы также можете запустить анализ через плагин для IntelliJ IDEA, но вы не можете выбрать отдельные файлы для анализа. Окно предупреждения выглядит так:
На мой взгляд, работать с предупреждениями не очень удобно, так как их невозможно сгруппировать по файлам и неочевидным сообщениям. Они появляются только при наведении курсора на предупреждение.
Заключение
Конечно, помимо выше рассмотренных анализаторов, есть и другие решения. Существуют как платные (Coverity, Klockwork, JArchitect), так и бесплатные (Error Prone, Infer, Checkstyle) программы. Все они сосредоточены на одном: предотвратить попадание некорректного или потенциально ошибочного кода в производство. Я не имею права судить, какой из анализаторов лучше подходит для этой задачи. Но анализаторы, разрабатывающие анализ потока данных и символьное выполнение, с большей вероятностью обнаружат реальную ошибку в коде.
Если вы выбираете статический анализатор, обратите внимание на:
Примечание: я привел примеры с интеграцией в IntelliJ IDEA, так как часто использую ее.
Ошибки в куче и стековой памяти Java
Основное исключение, которое описывает проблему с кучей памяти — это .
Java Heap Space
Эта ошибка возникает, когда программе Java не удалось выделить новый объект в области памяти кучи.
GC Overhead Limit Exceeded
Программа Java тратит слишком много времени на сборку мусора. Такая ошибка появляется тогда, когда сборка мусора занимает 98% времени программы и восстанавливает менее 2% пространства памяти.
Здесь содержит ссылку на наши сгенерированные строки, поэтому сборщик мусора не может удалить сгенерированные строки из памяти, а пытается удалить любой другой мусор в приложении. Но этого недостаточно.
Запрошенный размер массива превышает предел виртуальной машины (Requested Array Size Exceeds VM Limit)
Ошибка возникает при попытке выделить массив, когда места в куче недостаточно.
Метапространство (Metaspace)
Исключение выдается с этим сообщением, когда в области метапространства нет места для информации о данных класса.
Нет места для подкачки (Request Size Bytes for Reason. Out of Swap Space?)
Ошибка появляется, когда не удалось выделить память в собственной куче или ее размер недостаточен.
Reason stack_trace_with_native_method
Собственный интерфейс Java или собственный метод не смогли выделить память в куче.
— когда слишком много вызовов методов. Обычно исключение вызывается методом, внутри которого есть рекурсия.
Всем привет, JavaRush сообщество.
Сегодня поговорим о дебаге: что это такое и как дебажить в Intellij IDEA.
Статья рассчитана на людей, у которых есть уже минимальные знания Java Core. Здесь не будет ни фреймворков, ни сложных процессов публикации библиотек. Легкая прогулка. Так что располагайтесь поудобнее — начнем!
Что такое Debug
Debug — это процесс отладки (проверки) кода, когда в процессе его выполнения можно остановиться в обозначенном месте и посмотреть за ходом выполнения. Понять, в каком состоянии находится программа в определенном месте.
Это точно так же, как если бы можно было остановить жизнь и посмотреть на всё со стороны. Круто, правда?
Наша задача состоит в том, чтобы быстро и просто научиться проводить отладку приложений при помощи всеми нами любимой среды разработки Intellij IDEA.
Что нужно для начала отладки
Даю бесплатный совет: пока читаете статью, проделывайте все то, что здесь будет описано, благо есть все для этого.
Что нужно:
Выбираем проект , нажимаем и получаем:
Оставляем import project from external sources, Maven и нажимаем .
Импортировав проект, можем описать процесс на живом примере.
Чтобы начать мало-мальски дебажить, нужно понять, что такое и разобраться в нескольких горячих клавишах, которые нужны для начала.
— это специальный маркер, который отображает место или
состояние, на котором нужно остановить приложение.
Поставить breakpoint можно либо нажав левой кнопкой мыши на левую боковую панель, либо кликнув курсором по месту кода и нажав Ctrl + F8.
Breakpoint’ы бывают трех видов: метка на строку, метка на переменную и метка на метод.
Выглядит это так:
Breakpoint’ы можно удалить, выполнив те же действия, что и при их добавлении.
Бывают ситуации, когда нужно сделать их неактивными (замьютить). Для этого в Debug секции, можно найти значок
, который сделает все breakpoint’ы неактивными.
Чтобы посмотреть, какие уже выставленные breakpoint’ы, можно или зайти в Debug в левом нижнем углу и найти иконку
, или нажать :
Когда зайдем в список breakpoint’ов, увидим:
Здесь есть два preakpoint’a:
Хочу заметить, что при клонировании проекта к себе не будет этих BreakPoint’ов: их нужно выставить самостоятельно!
Также есть секция Java Exception Breakpoints. Очень полезная вещь. При помощи ее можно добавить неявный breakpoint, чтобы программа останавливалась перед выбрасыванием любого исключения или какого-то конкретного.
Добавим для RuntimeException неявный breakpoint. Делается это легко: в верхнем левом углу есть плюсик “+”. Нажимаем на него и выбираем Java Exceptions Breakpoints:
В появившемся окне пишем имя исключения, которое нужно добавить, выбираем из предложенного списка и нажимаем :
На этом ликбез заканчиваем и переходим к практике.
Поехали, будем врываться в дебри дебага
Так как я потомственный пчеловод, для презентации отладки создал проект, который описывает процесс сбора нектара пчелами, переработки нектара в мед и получение меда из улья.
На основе документации
README файла, который лежит в корне проекта, читаем: — со всех цветков, с которых собирают нектар (как значение), будет собрано количество меда, равное половине собранного нектара.
В проекте есть такие классы:
Исключение выбрасывается справедливо, так как значение количества нектара, которое есть в медоносе, не может быть отрицательным. Но почему же так происходит? Ведь есть же проверка, что если нектар закончился, то возвращается нулевое значение в строках 15-17:
README файле написано, что нектар переходит в мед с пропорцией 2 к 1:
## Documentation
Presentation based on honey getting process.
**Note**: 1 honey point = 2 nectar points
Поэтому нам, чтобы зайти в работу метода beeHive.populateHoney(), нужно нажать F7, и мы перейдем далее:
Далее, проходим в режиме дебага используя по этому методу до конца и опишем, что происходит в этом методе:
Вот куда делись эти две единицы, ура! После общения с бизнес-аналитиком приходим к выводу, что
README файл содержит ошибку, и его нужно будет обновить.
Обновим README файл:
## Documentation
Presentation based on honey getting process.
**Note**:
* 1 honey point = 2 nectar points
* 2 honey point queen bee eats every time when beehive populates the honey.
И все:, все найденные баги починены, можем спокойно продолжать с умным видом пить кофе и читать статейки на
Подведем итог
За эту статью мы разобрались, что:
Debugging в переводе с английского означает «Отладка». Она необходима в программировании Java, чтоб отслеживать логические ошибки в коде. И инструменты NetBeans позволяют это сделать.
Логические ошибки – это ошибки программиста, когда код работает не так, как вы ожидали. Их может быть трудно отследить. К счастью, в NetBeans есть несколько встроенных инструментов, которые помогут вам найти решение этой проблемы.
Для начала изучите этот код:
ErrorsHand
main args
LetterCount
check_word
single_letter
i
i i check_wordlength i
single_letter check_wordsubstring
single_letterequals
LetterCount
outprintln”G было найдено ” LetterCount
Введите этот код либо в проект, который у вас уже есть, либо запустив новый. В этом коде мы пытаемся подсчитать, сколько раз встречается буква «g» в слове «Debugging». Ответ очевиден 3. Однако, когда вы запускаете программу, в окне «Вывод» выведется:
Итак, мы сделали где-то в нашем коде ошибку. Но где? Java-программа выполняется нормально и не выдает никаких исключений для изучения в окне вывода. Так что делать?
Чтобы отследить проблемы с вашим кодом, NetBeans позволяет вам добавить нечто, называемое точкой остановки (Breakpoint).
Чтоб добавить новую точку остановки, нажмите в поле нумерации строк в NetBeans окна кода напротив той строки, которую хотите проверить:
NetBeans перейдет к точке остановки и строка станет зеленого цвета. Сейчас он остановил выполнение кода. Также вы должны увидеть новую панель инструментов:
Вы можете нажать клавишу F5 и продолжить. Код должен работать как обычно с точкой остановки. Сеанс debugging завершится.
Когда сеанс debugging завершится, нажмите на точку остановки, чтобы избавиться от нее. Теперь добавьте точку остановки в цикл for:
Добавьте еще один Watch и введите single_letter. Нажмите ОК. Добавьте третий Watch и введите LetterCount. Вы должны увидеть эти три переменные внизу экрана:
Теперь нажмите значок Step Into на панели инструментов:
Или просто нажмите клавишу F7 на клавиатуре. Продолжайте нажимать F7 и наблюдайте, что происходит в окне Watch.
Вы обнаружите, что переменная i каждый раз увеличивается на 1. Но две остальные переменные остаются прежними:
Поскольку в переменной single_letter ничего нет, то LetterCount не может выходить за пределы нуля. Итак, мы нашли нашу проблему – использование substring является неправильным, так как оно не захватывает символы, указанные в круглых скобках.
Остановите сеанс debugging и измените строку с substring следующим образом:
single_letter check_wordsubstringi i
Теперь снова запустите сеанс debugging. Продолжайте нажимать клавишу F7, чтобы пройти по каждой строке цикла for. На этот раз вы должны увидеть изменения переменных sinle_letter и LetterCount.
Запустите Java-программу, и вы увидите в окне «Вывод»:
Теперь у нас правильный ответ.
То есть, если ваш код работает не так, как планировалось, попробуйте установить точку остановки и несколько Watches для своих переменных. И начните сеанс debugging.
В следующем разделе мы рассмотрим совсем другую тему: как открывать текстовые файлы в Java.
Разработчики остро нуждаются в том, чтобы кто-то проверял их код. Особенно это касается начинающих разработчиков.
Но иногда проверка чужого кода занимает очень много времени, да и занятие это скучноватое. Однако игнорировать этот аспект разработки нельзя, ведь он напрямую влияет на качество продукта, да и на качество вас как разработчика в целом.
Поэтому ревью кода — обязательная часть разработки. Чтобы облегчить эту задачу, используются различные средства для статического анализа кода. Об одном из них мы поговорим сегодня.
Для начала уточним один момент. У нас уже есть Java-компилятор, который проверяет код, так в чем же его отличие от статического анализа?
проверяет байт-код Java (скомпилированные файлы с расширением .class) на наличие шаблонных ошибок, в то время как компилятор лишь проверяет исходный код на наличие синтаксических ошибок.
Такие средства помогают находить плохие решения, неиспользуемый код, неэффективные решения, возможные ошибки и т.д.
Они облегчают жизнь ревьюеров кода и позволяют отлавливать то, что они могут пропустить или не учесть при проверке.
Если вы совсем новичок и ещё не работаете в компании на проекте, данные инструменты вам будут особенно полезны, так как они будут освещать недостатки вашего кода, и вы будете их подсознательно запоминать, чтобы в будущем не допускать повтора. Ну а впоследствии вы сами сможете стать крутым ревьюером, поскольку будете мгновенно замечать все недостатки кода.
Сегодня проведем небольшой обзор статического анализатора .
SpotBugs — это инструмент, который позволяет исследовать код для поиска возможных проблем. Он производит статический анализ, просматривая код, чтобы найти определенные антипаттерны, которые могут вызывать проблемы (например, низкую производительность). Инструмент, который выполняет эти проверки автоматически, при каждом изменении, спасет код от постепенного ухудшения. Если не настроить этот процесс, незаметно для всех, в какой-то момент может стать слишком поздно, ведь код будет содержать сотни предупреждений.
Для корректной работы SpotBugs необходимо использовать Java версии 8 и выше.
Данный инструмент называют преемником (наследником) общеизвестного статического анализатора FindBugs.
можно в интеграции с:
Также возможно использование через скачивание и установку двоичного дистрибутива.
Мы с вами воспользуемся подключением через Maven.
Добавляем в Maven:
Также в разделе плагинов добавляем:
Основные команды SpotBugs
Ну а теперь давайте рассмотрим основные команды для SpotBugs, вызываемые либо через консоль Мавена:
(чтобы вызвать консоль, нужно нажать на значок ),
Либо через терминал idea:
Mvn spotbugs
Отображает справочную информацию для пользовательского интерфейса командной строки .
Пример результата вызова:
Данная команда запускает анализ и сообщает о неудачной сборке, если обнаруживает какие-либо ошибки из спектра .
Пример результата запуска команды:
Тут мы видим, как spotbugs ругается на все найденные недостатки приложения (на найденный плохой код).
Данная команда анализирует целевой проект с помощью SpotBugs. Без запуска данной команды, команда по отображению результатов фактически будет бесполезна, т.к. она и производит сам анализ.
После запуска данной команды создаётся файл , в котором и лежат результаты анализа для дальнейшего отображения.
Также следует отметить, что запуск команды сам по себе ничего не даст: сперва нужно запустить стандартную команду для компиляции проекта mvn clean compile, и только после неё — команду для анализа проекта.
Предыдущая рассмотренная команда, , также анализирует и создаёт файл , но в отличие от она ещё и показывает результат анализа на нижней панели.
Для анализа таким путём также сперва нужно запустить mvn clean compile, а только потом — .
Пожалуй, данная команда самая интересная: она запускает графический интерфейс SpotBugs для проверки результатов анализа, в котором вы можете подробно рассмотреть, какие недостатки есть в вашем кода и где они находятся.
Но, как я и упомянул выше, для правильной отработки данной команды необходим файл в папке , который создаётся после описанных выше манипуляций.
При запуске данной команды получаем следующее графическое отображение:
Тут вы можете настраивать фильтрацию по имени класса, группировать по категориям плохого кода и так далее.
Возможные недостатки делятся на типы, которые в свою очередь делятся на конкретные подробные шаблоны ошибок (400+).
Типы ошибок
Давайте же рассмотрим подробнее возможные типы ошибок:
Полное подробное описание ошибок вы можете найти в этой документации.
Файлы фильтров
Для отлова шаблонов “плохого кода” в используются фильтры. По сути фильтр сопоставляет экземпляры ошибок по набору критериев.
Собственно, вы можете составлять собственные вариации шаблонов плохого кода, которые нужно отловить (создать кастомные файлы фильтра).
Также с помощью данных файлов фильтров вы можете задавать ошибки, которые нужно исключать при проверке. Возможно, у вас в проекте что-то будет считаться хорошим решением, что по умолчанию фиксируется в анализаторе как плохая практика.
Файл фильтра — это XML-документ с элементом верхнего уровня, у которого есть некоторое количество дочерних элементов . Каждый элемент представляет собой предикат, который применяется к сгенерированным экземплярам ошибок.
Подробнее о создании файла фильтра можно почитать в этой документации.