Перевірки та налагодження

Assert і перевірки користувацьких даних

Інструкція assert призначена для внутрішніх припущень розробника. За замовчуванням assertions не виконуються; ключ JVM -ea їх вмикає. Тому assert не підходить як єдина перевірка числа з консолі або доступу до операції.

public class AssertionDemo {
    public static void main(String[] args) {
        int[] values = {1, 2, 3};
        assert values.length > 0 : "Порожній масив";
        int sum = 0;
        for (int value : values) sum += value;
        assert sum == 6 : "Порушений контрольний приклад";
        System.out.println(sum);
    }
}

java -ea AssertionDemo

Не ставте важливий побічний ефект у вираз assert: без -ea він не виконається. Для вимоги до публічного методу використовуйте явний if і відповідний виняток. Для повторюваного набору перевірок у темі 13 застосовуватиметься JUnit.

Рис. 4.5. Опція JVM для перевірок assert

Трасування стека та причин

Перший рядок трасування містить тип і повідомлення. Далі йдуть кадри викликів, зазвичай від місця помилки до викликача. Caused by показує початкову причину, а Suppressed – додатковий збій, наприклад закриття. Почніть із першого кадру власного коду, але не ігноруйте вкладену причину.

Рис. 4.6. Власний кадр і початкова причина винятку

Номер рядка має сенс лише для конкретної версії вихідного коду. Якщо користувач повідомляє про збій старої збірки, рядок у поточному файлі може вже містити іншу інструкцію. Зберігайте версію програми, коміт і мінімальний набір даних для відтворення.

Текст винятку не слід використовувати як надійний машинний протокол. Власні стабільні коди помилок або типи кращі за пошук слова «invalid» у повідомленні, яке може змінитися між версіями або локалями.

Налагодження в IntelliJ IDEA

Документація налагоджувача: https://www.jetbrains.com/help/idea/debugging-code.html. Точка зупинки дозволяє побачити стан до виконання конкретної інструкції. Запускайте конфігурацію через Debug, а не звичайний Run. Після зупинки перевірте поточний потік, кадр і значення змінних.

Step Over виконує виклик як один крок, Step Into переходить усередину, Step Out завершує поточний метод. Resume продовжує до наступної зупинки. Назви й комбінації клавіш залежать від keymap; орієнтуйтеся на призначення дії.

Приклад 4. Середнє додатних значень

Потрібно усереднити лише додатні елементи. Якщо таких немає, повернути null. Помилка ділення на довжину всього масиву не викликає винятку, але порушує математичний контракт.

public class PositiveAverage {
    static Double average(int[] values) {
        long sum = 0;
        int count = 0;
        for (int value : values) {
            if (value > 0) {
                sum += value;
                count++;
            }
        }
        if (count == 0) return null;
        return (double) sum / count;
    }

    public static void main(String[] args) {
        System.out.println(average(new int[]{10, -5, 20}));
        System.out.println(average(new int[]{-5, 0}));
    }
}

Очікується 15.0, потім null. Перед поверненням для першого набору sum = 30, count = 2, values.length = 3. Неправильний знаменник дає 10, що виглядає звичайним числом. Саме тому потрібен контрольний набір із сумішшю прийнятих і відхилених даних.

Рис. 4.7. Локальні змінні перед обчисленням середнього

У Evaluate Expression порівняйте обидва вирази. Не викликайте там метод, який списує кошти, змінює колекцію чи записує файл: обчислення виразу може мати побічний ефект і змінити досліджуваний стан. Перегляд не завжди є пасивною дією.

Рис. 4.8. Порівняння двох знаменників

Умовна точка зупинки корисна для конкретного індексу або значення. Для довгого циклу задайте умову на кшталт value < 0, щоб не проходити всі ітерації вручну. Умова повинна бути безпечною і не змінювати стан програми.

Рис. 4.9. Умовна точка зупинки

Точка зупинки на винятку може спрацьовувати для перехопленого й неперехопленого винятку. Вона корисна, коли верхній catch приховує місце походження помилки. Оберіть потрібний тип, інакше великий застосунок зупинятиметься на кожному внутрішньому винятку бібліотеки.

Рис. 4.10. Зупинка на виникненні NumberFormatException

Протокол перевірки помилок

Для кожної відмови визначте: тип причини, місце перехоплення, текст для користувача, код завершення і стан після операції. Окремо перевірте, що успішний результат не друкується після відмови. Якщо операція змінює стан, порівняйте його до й після збою.

Для Payment потрібні правильне списання, точне вичерпання залишку, сума понад залишок, нульова сума й неправильний текст. Для ресурсу потрібні успіх, виняток у тілі та одночасний збій тіла й закриття. Один try навколо всього main не замінює цих предметних перевірок.

Виправлення логічної помилки завершується новим контрольним прикладом. Якщо помилка середнього виникала лише за наявності від’ємного елемента, після виправлення цей випадок має залишитися в наборі перевірок. Тест лише додатного масиву не відрізняє правильний знаменник від неправильного.