How to use the free code checker
Code
Copy and paste your Java code into the editor.
Language
Select your language from the dropdown.
Check
Click the Check code button.
Improve
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.
This free web based Java code checker is powered by Snyk Code. Sign up now to get access to all the features including vulnerability alerts, real time scan results, and actionable fix advice within 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.
Real-time
Scan and fix source code in minutes.
Actionable
Fix vulns with dev friendly remediation.
Integrated in IDE
Find vulns early to save time & money.
Ecosystems
Integrates into existing workflow.
More than syntax errors
Comprehensive semantic analysis.
AI powered by people
Modern ML directed by security experts.
In-workflow testing
Automatically scan every PR and repo.
CI/CD security gate
Integrate scans into the build process.
Frequently asked questions
Вчера всё работало, а сегодня не работает / Код не работает как задумано
или
Debugging (Отладка)
В чем заключается процесс отладки? Что это такое?
Процесс отладки состоит в том, что мы останавливаем выполнения скрипта в любом месте, смотрим, что находится в переменных, в функциях, анализируем и переходим в другие места; ищем те места, где поведение отклоняется от правильного.
Заметка: Отладка производится как правило в IDE (Интегрированная среда разработки). Что это такое можно чуть подробнее ознакомиться в вопросе
Какие есть способы предупреждения ошибок, их нахождения и устранения?
В данном случае будет рассмотрен пример с Intellij IDEA, но отладить код можно и в любой другой IDE.
Подготовка
Достаточно иметь в наличии IDE, например Intellij IDEA
Запуск
Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение Java, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.
Отладка запускается сочетанием Shift+F9 или выбором в верхнем меню Run → Debug или нажатием зеленого «жучка»:
В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет метод, выполнение «заморозится» на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку в UI, передача POST запроса с данными и прочие другие действия)
Цифрами обозначены:
- Стэк вызовов, все вложенные вызовы, которые привели к текущему месту кода.
- Переменные. На текущий момент строки ниже номера 24 ещё не выполнилась, поэтому определена лишь
dataиnumsStringArr - Показывает текущие значения любых переменных и выражений. В любой момент здесь можно нажать на
+, вписать имя любой переменной и посмотреть её значение в реальном времени. Напримерdataилиnums[0], а можно иnums[i]иitem.test.data.name[5].info[key[1]]и т.д. На текущий момент строки ниже номера 24 ещё не выполнилась, поэтомуsumиoutputво вкладкеWatchersобозначены красным цветом с надписью «cannot find local variable».
Процесс
Для самого процесса используются элементы управления (см. изображение выше, выделено зеленым прямоугольником) и немного из дополнительно (см. изображение выше, выделено оранжевым прямоугольником)
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 — Отключить брейкпойнты.
…
Итак, в текущем коде видно значение входного параметра:
data = "23 24 11 18"— строка с данными через пробелnumsStringArr = {"23", "24", "11", "18"}— массив строк, который получился из входной переменной.
Если нажмем F8 2 раза, то окажемся на строке 27; во вкладках Watches и Variables и в самой странице с кодом увидим, что переменная sum была инициализирована и значение равно 0, а также nums инициализирована и в ней лежит массив целых чисел {23, 24, 11, 18} .
Если теперь нажмем F8, то попадем внутрь цикла for и нажимая теперь F8 пока не окончится цикл, можно будет наблюдать на каждой итерации, как значение num и sum постоянно изменяются. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.
Дальнейшие нажатия F8 переместит линию кода на строки 31, 32 и, наконец, 36.
Дополнительно
Если нажать на View Breakpoints в левой панели, то можно не только посмотреть все брейкпойнты, но в появившемся окно можно еще более тонко настроить условие, при котором на данной отметке надо остановиться. В методе выше, например, нужно остановиться только когда sum превысит значение 20.
Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).
Больше информации об отладке можно посмотреть в http://learn.javajoy.net/debug-intellij-idea, а также в официальной документации к IDE
Используйте assertions (утверждения или ассерты) Java для проверки корректности кода и для ускорения тестирования и отладки ваших программ.
Джефф Фризен
Написание программ, которые правильно работают, может оказаться сложной задачей. Поскольку наши предположения о том, как будет вести себя код при выполнении, часто ошибочны. Использование ассертов в Java — это один из способов проверить правильность логики программирования.
В этом руководстве рассказывается об ассертах в Java. Сначала вы узнаете, что такое ассерты и как их определять и использовать в коде. Далее вы узнаете, как использовать ассерты для обеспечения выполнения предварительных и постусловий. Наконец, вы сравните ассерты с исключениями и выясните, зачем в коде нужно и то и другое.
Загрузите исходный код примеров для этой статьи. Создано Джеффом Фризеном для JavaWorld.
До JDK 1.4 разработчики часто использовали комментарии для документирования предположений о правильном использовании методов программы. Однако комментарии бесполезны как механизм для проверки и отладки предположений. Компилятор игнорирует комментарии, поэтому нет возможности использовать их для обнаружения ошибок. Разработчики также часто не обновляют комментарии при изменении кода.
В JDK 1.4 ассерты были введены как новый механизм для тестирования и отладки кода. По сути, ассерты — это компилируемые сущности, которые выполняются в runtime, если вы включили их для тестирования программы. Вы можете запрограммировать ассерты так, чтобы они уведомляли вас об ошибках ещё до того как они произошли и программа “упала”, что значительно сокращает время на отладку неисправной программы.
Ассерты используются для определения требований, исполнение которых делают программу правильной. И делается это при помощи проверки условий (логических выражений) на true. Если же выражение выдаёт false, разработчик получает уведомление об этом. Использование утверждений может значительно повысить вашу уверенность в правильности кода.
Как написать ассерт на Java
Ассерты реализуются с помощью оператора assert и класса java.lang.AssertionError. Этот оператор начинается с ключевого слова assert и продолжается логическим выражением. Синтаксически это выражается следующим образом:
assert BooleanExpr;
Если значение BooleanExpr истинно, ничего не происходит и выполнение продолжается. Однако, если выражение оценивается как ложное, бросается AssertionError, как, например, в этом коде:
Листинг 1: AssertDemo.java (версия 1)
public class AssertDemo
{
public static void main(String[] args)
{
int x = -1;
assert x >= 0;
}
}
ассерт здесь говорит о том, что по мнению разработчика переменная x должна быть больше или равна 0. Однако это явно не так; выполнение оператора assert приводит к выбросу AssertionError.
Скомпилируйте этот код (javac AssertDemo.java) и запустите его с включенными ассертами (java -ea AssertDemo) (прим.пер.: все популярные среды программирования позволяют включать ассерты через настройку). Вы увидите следующий результат:
Exception in thread "main" java.lang.AssertionError
at AssertDemo.main(AssertDemo.java:6)
Это сообщение несколько загадочно, так как не указывает, что привело к AssertionError. Если вам нужно более информативное сообщение, используйте assert с таким синтаксисом:
assert BooleanExpr : expr;
Здесь expr любое выражение, включая вызов метода (прим.пер.: в соответствии с лучшими современными практиками рекомендуется отказаться от вызовов методов из ассертов), которое должно возвращать значение — вы не можете вызвать метод void. Удобно использовать просто строку, описывающую причину сбоя, как показано ниже:
Листинг 2: AssertDemo.java (версия 2)
public class AssertDemo
{
public static void main(String[] args)
{
int x = -1;
assert x >= 0: "x < 0";
}
}
Запустите этот код с включенными ассертами. На этот раз вы увидите чуть больше информации, объясняющей причину выброса AssertionError:
Exception in thread "main" java.lang.AssertionError: x < 0
at AssertDemo.main(AssertDemo.java:6)
Для любого из этих примеров, выполнение AssertDemo без -ea опции (enable assertions) не приведет к бросанию исключения. Если ассерты отключены, они не выполняются, хотя и присутствуют в файле класса.
Предварительные условия и постусловия
Ассерты проверяют предварительные и постусловия на true, и предупреждают разработчика, когда происходит нарушение:
- Предварительное условие — это условие, которое должно оцениваться как истинное перед выполнением некоторого метода. Выполнение предварительных условий гарантирует, что вызывающие методы соблюдают контракты с вызываемыми методами.
- Постусловие предполагает проверку на true после выполнения некоторой кодовой последовательности. Постусловия гарантируют, что вызываемые методы соблюдают свои контракты с вызывающими.
Предварительные условия
Вы можете обеспечить выполнение предварительных условий для общедоступных конструкторов и методов, выполнив явные проверки и выбрасывая исключения при необходимости. Для private вспомогательных методов вы можете обеспечить выполнение предварительных условий, используя ассерты. Рассмотрим листинг 3.
Листинг 3: AssertDemo.java (версия 3)
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.IOException;
class PNG
{
/**
* Create a PNG instance, read specified PNG file, and decode
* it into suitable structures.
*
* @param filespec path and name of PNG file to read
*
* @throws NullPointerException when <code>filespec</code> is
* <code>null</code>
*/
PNG(String filespec) throws IOException
{
// Enforce preconditions in non-private constructors and
// methods.
if (filespec == null)
throw new NullPointerException("filespec is null");
try (FileInputStream fis = new FileInputStream(filespec))
{
readHeader(fis);
}
}
private void readHeader(InputStream is) throws IOException
{
// Confirm that precondition is satisfied in private
// helper methods.
assert is != null : "null passed to is";
}
}
public class AssertDemo
{
public static void main(String[] args) throws IOException
{
PNG png = new PNG((args.length == 0) ? null : args[0]);
}
}
Создание экземпляра класса PNG в этом коде является необходимым для чтения и декодирования PNG (Portable Network Graphics) файлов изображений. Конструктор явно сравнивает filespec с null, выбрасывая NullPointerException, если он равен null. Смысл в том, чтобы обеспечить соблюдение предусловия, которое предполагает, что filespec не может быть равным null.
Однако нецелесообразно указывать assert filespec != null;, потому что предварительное условие, упомянутое в документации Javadoc конструктора, не будет (технически) проверяться, когда ассерты отключены (в данном случае, эта проверка будет просто страховкой, потому что FileInputStream()и без нас бросит NullPointerException, но негоже зависеть от недокументированного поведения).
С другой стороны, assert будет хорош во вспомогательном private методе readHeader(), который в конечном итоге завершится чтением и декодированием 8-байтового заголовка PNG файла. Предварительное условие здесь также состоит в том, что параметр is не должен быть равен null.
Постусловия
Постусловия обычно указываются через ассерты, независимо от того, является ли метод (или конструктор) общедоступным. Рассмотрим такой код:
Листинг 4: AssertDemo.java (версия 4)
public class AssertDemo
{
public static void main(String[] args)
{
int[] array = { 20, 91, -6, 16, 0, 7, 51, 42, 3, 1 };
sort(array);
for (int element: array)
System.out.printf("%d ", element);
System.out.println();
}
private static boolean isSorted(int[] x)
{
for (int i = 0; i < x.length - 1; i++)
if (x[i] > x[i + 1])
return false;
return true;
}
private static void sort(int[] x)
{
int j, a;
// For all integer values except the leftmost value ...
for (int i = 1; i < x.length; i++)
{
// Get integer value a.
a = x[i];
// Get index of a. This is the initial insert position, which is
// used if a is larger than all values in the sorted section.
j = i;
// While values exist to the left of a's insert position and the
// value immediately to the left of that insert position is
// numerically greater than a's value ...
while (j > 0 && x[j - 1] > a)
{
// Shift left value -- x[j - 1] -- one position to its right --
// x[j].
x[j] = x[j - 1];
// Update insert position to shifted value's original position
// (one position to the left).
j--;
}
// Insert a at insert position (which is either the initial insert
// position or the final insert position), where a is greater than
// or equal to all values to its left.
x[j] = a;
}
assert isSorted(x): "array not sorted";
}
}
В этом коде представлен вспомогательный метод sort(), который использует алгоритм сортировки вставкой для массива целочисленных значений. Я имел обыкновение проверять постусловие сортировки x через assert перед возвратом методом sort() результата вызывающему коду.
Этот пример демонстрирует важную характеристику ассертов — их выполнение, обычно, ресурсозатратно. По этой причине в промышленной версии программы ассерты обычно отключены. В методе isSorted() необходимо сканировать весь массив, что может занять много времени в случае большого массива.
Ассерты против исключений в Java
Разработчики используют ассерты для документирования логически запрещённых ситуаций и для обнаружения ошибок в логике программы. Во время её выполнения включенный ассерт предупреждает разработчика о логической ошибке. Разработчик меняет исходный код, чтобы исправить логическую ошибку, а затем перекомпилирует этот код.
Разработчики используют механизм исключений Java для ответа на нефатальные (например, нехватку памяти) ошибки, которые могут быть вызваны факторами окружающей среды, такими как несуществующий файл, или плохо написанным кодом, например попыткой разделить на 0. Обработчик исключений часто пишется так, чтобы после ошибки программа могла продолжить работу.
Ассерты не заменяют исключения. В отличие от исключений, ассерты не поддерживают восстановление после ошибок (ассерты обычно немедленно останавливают выполнение программы — AssertionError не предназначены для перехвата); они часто отключены в промышленном коде; и они обычно не отображают удобные для пользователя сообщения об ошибках (хотя это не проблема assert). Важно знать, когда использовать исключения, а не ассерты.
Когда использовать исключения
Предположим, вы написали sqrt()метод, который вычисляет квадратный корень из своего параметра. В контексте действительных чисел невозможно извлечь квадратный корень из отрицательного числа. Следовательно, вы используете ассерт для отказа от исполнения метода, если аргумент отрицательный. Рассмотрим следующий фрагмент кода:
public double sqrt(double x)
{
assert x >= 0 : "x is negative";
// ...
}
Неуместно использовать ассерт для проверки аргумента в этом public методе. Ассерт предназначен для обнаружения ошибок в логике программирования, а не для защиты метода от ошибочных значений параметров. Кроме того, если ассерты отключены, невозможно решить проблему отрицательного аргумента. Лучше создать исключение следующим образом:
public double sqrt(double x)
{
if (x < 0)
throw new IllegalArgumentException("x is negative");
// ...
}
Разработчик может выбрать, обрабатывать исключение недопустимого аргумента или пробросить его, и тогда сообщение об ошибке отображается инструментом, запускающим программу. Прочитав сообщение об ошибке, разработчик может исправить код, вызвавший исключение.
Вы могли заметить тонкую разницу между ассертом и условием обнаружения ошибок. Ассерт требует x >= 0, а условие обнаружения ошибок: x < 0. Ассерт оптимистичен: мы предполагаем, что аргумент в порядке. Напротив, условие обнаружения ошибок пессимистично: мы предполагаем, что аргумент неверен. Ассерты документируют правильную логику, тогда как исключения документируют неправильное поведение во время выполнения.
В этом руководстве вы узнали, как использовать ассерты для документирования правильной логики программы. Вы также узнали, почему ассерты не заменяют исключения, и вы видели пример, в котором использование исключения было бы более эффективным.
Этот рассказ «Как использовать ассерты в Java» был первоначально опубликован JavaWorld .
Оригинал
Перевод Академии Progwards
Java 8 makes this a lot easier, and Kotlin/Scala doubly so.
We can write a little utility class
class MyAssertions{
public static void assertDoesNotThrow(FailingRunnable action){
try{
action.run()
}
catch(Exception ex){
throw new Error("expected action not to throw, but it did!", ex)
}
}
}
@FunctionalInterface interface FailingRunnable { void run() throws Exception }
and then your code becomes simply:
@Test
public void foo(){
MyAssertions.assertDoesNotThrow(() -> {
//execute code that you expect not to throw Exceptions.
}
}
If you dont have access to Java-8, I would use a painfully old java facility: aribitrary code blocks and a simple comment
//setup
Component component = new Component();
//act
configure(component);
//assert
/*assert does not throw*/{
component.doSomething();
}
And finally, with kotlin, a language I’ve recently fallen in love with:
fun (() -> Any?).shouldNotThrow()
= try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }
@Test fun `when foo happens should not throw`(){
//...
{ /*code that shouldn't throw*/ }.shouldNotThrow()
}
Though there is a lot of room to fiddle with exactly how you want to express this, I was always a fan of fluent assertions.
Regarding
You’re approaching this the wrong way. Just test your functionality: if an exception is thrown the test will automatically fail. If no exception is thrown, your tests will all turn up green.
This is correct in principle but incorrect in conclusion.
Java allows exceptions for flow of control. This is done by the JRE runtime itself in APIs like Double.parseDouble via a NumberFormatException and Paths.get via a InvalidPathException.
Given you’ve written a component that validates Number strings for Double.ParseDouble, maybe using a Regex, maybe a hand-written parser, or perhaps something that embeds some other domain rules that restricts the range of a double to something specific, how best to test this component? I think an obvious test would be to assert that, when the resulting string is parsed, no exception is thrown. I would write that test using either the above assertDoesNotThrow or /*comment*/{code} block. Something like
@Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
//setup
String input = "12.34E+26" //a string double with domain significance
//act
boolean isValid = component.validate(input)
//assert -- using the library 'assertJ', my personal favourite
assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
assertDoesNotThrow(() -> Double.parseDouble(input));
}
I would also encourage you to parameterize this test on input using Theories or Parameterized so that you can more easily re-use this test for other inputs. Alternatively, if you want to go exotic, you could go for a test-generation tool (and this). TestNG has better support for parameterized tests.
What I find particularly disagreeable is the recommendation of using @Test(expectedException=IllegalArgumentException.class), this exception is dangerously broad. If your code changes such that the component under test’s constructor has if(constructorArgument <= 0) throw IllegalArgumentException(), and your test was supplying 0 for that argument because it was convenient —and this is very common, because good generating test data is a surprisingly hard problem—, then your test will be green-bar even though it tests nothing. Such a test is worse than useless.
Тестирование кода на наличие исключений — важная составляющая процесса разработки. В Java для этого можно использовать фреймворк JUnit. Основная проблема
Тестирование кода на наличие исключений — важная составляющая процесса разработки. В Java для этого можно использовать фреймворк JUnit. Основная проблема в том, как идиоматически использовать JUnit, чтобы проверить, что некоторый код выбрасывает исключение.
Рассмотрим типичный сценарий. Допустим, есть метод, который должен выбрасывать исключение IndexOutOfBoundsException при выполнении определенной операции. Как это можно проверить с помощью JUnit?
@Test
public void testMethodThrowsException() {
boolean exceptionThrown = false;
try {
someMethod();
} catch (IndexOutOfBoundsException e) {
exceptionThrown = true;
}
assertTrue(exceptionThrown);
}
В этом коде мы вызываем метод someMethod(), который, как мы ожидаем, должен выбросить IndexOutOfBoundsException. Если исключение выброшено, то мы устанавливаем флаг exceptionThrown в true и затем проверяем его значение.
Однако, в JUnit есть более изящные и короткие способы проверки исключений.
Использование аннотации @Test(expected = Exception.class)
Самый простой способ — это использование аннотации @Test с параметром expected. Этот параметр принимает класс исключения, которое мы ожидаем увидеть. Вот как это выглядит на практике:
@Test(expected = IndexOutOfBoundsException.class)
public void testMethodThrowsException() {
someMethod();
}
Если метод someMethod() выбросит IndexOutOfBoundsException, то тест пройдет, иначе он упадет, что и требуется.
Использование assertThrows()
В JUnit 5 представлен новый метод assertThrows(), который позволяет более явно и гибко управлять процессом проверки исключений.
@Test
public void testMethodThrowsException() {
assertThrows(IndexOutOfBoundsException.class, () -> {
someMethod();
});
}
В этом случае, assertThrows() принимает два аргумента: класс исключения и лямбда-выражение с вызовом метода.
Использование assertThrows() дает больше гибкости, так как позволяет проверить не только тип исключения, но и его сообщение или другие свойства.
Таким образом, в JUnit есть несколько способов проверки исключений, и их выбор зависит от конкретной ситуации и предпочтений разработчика.