[Совет по Java #027]

Тема: double и float не подходят для циклов с условием на равенство.

Проблема: Числа с плавающей запятой (float, double) не могут быть точно представлены в двоичной системе.

Значение 0.1 в двоичном виде — это бесконечная периодическая дробь, поэтому в памяти хранится его приближение. При многократном прибавлении 0.1 к 0.0 накопленная погрешность приводит к тому, что переменная никогда не станет точно равной 1.0. В результате условие d != 1.0 остается истинным всегда, и цикл становится бесконечным.

Это классическая ошибка, особенно опасная в алгоритмах численного анализа, обработке сигналов и финансовых расчетах, где невнимательность к погрешности может привести к зависанию программы или некорректным результатам.

Решение: Никогда не используйте операторы равенства (==, !=) с числами с плавающей запятой в условиях циклов.

Вместо этого задавайте условие через сравнение с порогом (эпсилон) или используйте целочисленный счетчик, преобразуя его в плавающее значение на каждой итерации. Для известного количества итераций применяйте целочисленный цикл.

Для проверки близости используйте Math.abs(a - b) < epsilon.

public class FloatLoopProblem {
    
    //Антипаттерн: бесконечный цикл
    public static void badLoop() {
        int iterations = 0;
        for (double d = 0.0; d != 1.0; d += 0.1) {
            iterations++;
            System.out.printf("Итерация %d: %.20f%n", iterations, d);
            if (iterations > 20) break; // защита от вечности
        }
        // Реальный вывод: d проходит через 0.0, 0.1, 0.2, ..., 0.9, 1.0000000000000002, ...
        // Никогда не равно 1.0
    }
    
    //Ошибка с float
    public static void badFloatLoop() {
        for (float f = 0.0f; f != 1.0f; f += 0.1f) {
            // Тоже бесконечный
        }
    }
    
    //Решение 1: целочисленный счетчик
    public static void goodLoopWithCounter() {
        for (int i = 0; i <= 10; i++) {
            double d = i * 0.1; // Вычисляем на каждой итерации
            System.out.println("d = " + d);
        }
    }
    
    //Решение 2: сравнение с эпсилон (допуском)
    public static void goodLoopWithEpsilon() {
        double d = 0.0;
        final double EPSILON = 1e-10;
        while (Math.abs(d - 1.0) > EPSILON) {
            System.out.println("d = " + d);
            d += 0.1;
        }
        System.out.println("Достигнуто: " + d);
    }
    
    //Решение 3: фиксированное количество итераций
    public static void goodFixedIterations() {
        int steps = 10;
        for (int step = 0; step <= steps; step++) {
            double ratio = (double) step / steps; // От 0.0 до 1.0
            System.out.println(ratio);
        }
    }
    
    // Демонстрация погрешности
    public static void demonstratePrecision() {
        double sum = 0.0;
        for (int i = 0; i < 10; i++) {
            sum += 0.1;
        }
        System.out.println("Сумма десяти 0.1: " + sum);           // 0.9999999999999999
        System.out.println("Сравнение с 1.0: " + (sum == 1.0)); // false
    }
    
    public static void main(String[] args) {
        demonstratePrecision();
        goodLoopWithCounter();
    }
}

Объяснение: Стандарт IEEE 754 определяет двоичное представление чисел с плавающей запятой. Десятичные дроби, не являющиеся суммой степеней двойки (например, 0.1 = 1/16 + 1/32 + 1/256 + ...), представляются бесконечным рядом, который обрезается до 53 бит мантиссы для double. Из-за этого ошибка округления накапливается.

В примере с циклом после десяти сложений получается не 1.0, а 0.9999999999999999. Условие d != 1.0 остается истинным, и цикл продолжается до бесконечности (точнее, до достижения бесконечности или переполнения).

Корректные подходы: использовать целочисленный счетчик (погрешность не накапливается, так как каждый раз вычисляется заново), применять сравнение с допустимой абсолютной погрешностью (epsilon), либо использовать BigDecimal для точных десятичных расчетов.

#Java #советы

С 11.04 по 17.04
Предыдущий пост(с 04.04 по 10.04)

Воскресный мотивационный пост:
Что случилось и почему сайт не работал или хронология одного хренового утра

Запись встреч/видео:
В процессе подготовки...

Обучающие статьи:
Раздел 9. Исключения, логирование, отладка

Глава 1. Иерархия исключений (Exceptions)
try-catch-finally – правильная обработка и освобождение ресурсов
try-with-resources (Java 7+) – автоматическое закрытие AutoCloseable

[Совет по Java #025]
Тема: ThreadLocal может вызвать утечку в серверах приложений.

[Совет по Java #026]
Тема: Синхронизация (synchronized) по строковой константе опасна.

[Совет по Java #027]
Тема: double и float не подходят для циклов с условием на равенство.

Полезные статьи и видео:
Где хранить код? Сравнение GitHub, GitLab и Bitbucket

Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование

Раздел 9. Исключения, логирование, отладка

Глава 1. Иерархия исключений (Exceptions)

throws в сигнатуре метода – проброс исключений наверх. Когда это оправдано

Ключевое слово throws в сигнатуре метода Java формирует явный контракт между реализацией и вызывающим кодом. Оно объявляет, что метод может завершиться не нормально, выбросив одно из перечисленных checked-исключений, и перекладывает обязанность обработки на вызывающую сторону. Это часть системы проверяемых исключений Java, где компилятор гарантирует, что каждый potential failure path либо обработан локально, либо явно проброшен дальше по стеку вызовов.

Сигнатура с throws создает сильную связанность (tight coupling) между уровнями абстракции. Когда метод объявляет throws IOException, он экспонирует деталь реализации — использование ввода-вывода — в публичный API. Это называется утечкой абстракции (abstraction leak), когда низкоуровневые детали просачиваются через интерфейсы высокоуровневых компонентов. Вызов такого метода вынуждает все вызывающие методы также объявлять IOException в своих сигнатурах, создавая каскадную зависимость, которая распространяется от инфраструктурного слоя до пользовательского интерфейса.


Когда проброс оправдан: сценарии восстановления

Объявление исключений в сигнатуре методologically оправдано только в ограниченном наборе сценариев.

Первичный критерий — возможность и вероятность восстановления от ошибки на уровне вызывающего кода. Если исключение представляет собой ожидаемое, восстановимое условие, и вызывающий код может принять осмысленное альтернативное действие, тогда throws уместен.

Пример восстановимого сценария — бизнес-исключение InsufficientFundsException в платежной системе. Вызывающий код (координатор транзакции) может перехватить это исключение и предпринять альтернативные действия: предложить пользователю другой способ оплаты, разбить платеж на части, или отложить операцию. В этом случае checked-исключение с throws в сигнатуре метода processPayment форсирует явную обработку критичного бизнес-сценария.

Другой допустимый случай — низкоуровневые API, где пользователь должен осознанно принять решение об обработке ресурсов. Например, конструктор FileInputStream объявляет throws FileNotFoundException, потому что отсутствие файла — это условие, которое вызывающий код может предвидеть и обработать (создать файл, запросить альтернативный путь, продолжить без файла).

Однако современная практика свидетельствует о том, что даже в этих сценариях часто предпочтительны unchecked-исключения с документированием через @throws в Javadoc, а не checked-исключения с throws в сигнатуре.


Exception Translation: оборачивание vs проброс

В многослойной архитектуре прямой проброс низкоуровневых исключений наверх считается антипаттерном. Вместо этого применяется паттерн Exception Translation — перехват низкоуровневого исключения и оборачивание его в высокоуровневое, соответствующее абстракции текущего слоя.

Рассмотрим типичный сценарий с доступом к данным:

// Антипаттерн: прямая передача SQLException через все слои
public User findUser(String id) throws SQLException {  // Нарушение абстракции
    return database.query("SELECT * FROM users WHERE id = ?", id);
}

// Паттерн Exception Translation: оборачивание в доменное исключение
public User findUser(String id) {
    try {
        return database.query("SELECT * FROM users WHERE id = ?", id);
    } catch (SQLException e) {
        throw new DataAccessException("Failed to load user: " + id, e);
    }
}

В этом примере DataAccessException — unchecked-исключение из Spring Framework, которое скрывает детали SQL, но сохраняет оригинальную причину (cause) для отладки. Это достигает нескольких целей: инкапсуляция деталей реализации, предоставление контекстно-зависимого сообщения об ошибке, и поддержание чистоты сигнатур методов бизнес-логики.


#Java #для_новичков #beginner #exception #throws