Почему выбрасывание RuntimeException считается плохой практикой?

Выбрасывание RuntimeException без должной необходимости считается плохой практикой по нескольким причинам:

1. Неинформативность: RuntimeException не требует обязательной обработки (checked exception). Выбрасывание такого исключения означает, что вызывающий код может не знать о возможности возникновения проблемы и не предпримет мер для ее устранения или обработки. Это делает код менее надежным и предсказуемым.
2. Скрытые ошибки: Если RuntimeException выбрасывается при условиях, которые могли бы быть обработаны на более высоком уровне, это может маскировать реальную причину проблемы. Исключение пробрасывается вверх по стеку вызовов и может быть поймано на гораздо более высоком уровне, где контекст ошибки уже потерян, что затрудняет отладку.
3. Трудность отладки: Поскольку RuntimeException не требуют объявления в сигнатуре метода (throws), они могут появиться где угодно, что усложняет поиск источника проблемы. Анализ стектрейса может потребовать больше времени.
4. Нарушение контракта: Выбрасывание RuntimeException при условиях, которые по сути являются частью ожидаемого поведения или возможным, но обрабатываемым сценарием ошибки, нарушает ожидаемый контракт метода. Метод должен либо вернуть результат, либо выбросить проверяемое исключение, четко указывая на возможный сбой.

Вместо необоснованного использования RuntimeException предпочтительно использовать:

• Проверяемые исключения (Checked Exceptions): Для ситуаций, которые могут разумно произойти в ходе выполнения программы и которые вызывающий код может обработать или от которых может восстановиться (например, IOException при работе с файлами).
• Проектирование без исключений: В случаях, когда ошибка может быть представлена возвращаемым значением (например, Optional) или индикатором статуса.
• Конкретные подклассы RuntimeException: Если ошибка действительно является неустранимой ошибкой программирования (например, NullPointerException при dereferencing null), использовать существующие стандартные исключения или создавать специфичные подклассы RuntimeException, которые более точно описывают проблему.

Пример:

Плохая практика:

// Плохо: выбрасывается RuntimeException без явного указания
public int divideBad(int a, int b) {
    if (b == 0) {
        throw new RuntimeException("Cannot divide by zero"); // Неинформативно, не требует обработки
    }
    return a / b;
}

Лучшая практика (использование проверяемого исключения):

// Хорошо: используется проверяемое исключение для явного указания возможной ошибки
public int divideGood(int a, int b) throws ArithmeticException { // Явно объявляем возможное исключение
    if (b == 0) {
        // Используем более специфичное и проверяемое исключение
        throw new ArithmeticException("Cannot divide by zero");
    }
    return a / b;
}

или (использование RuntimeException для невосстановимой ошибки):

// Хорошо: использование стандартного RuntimeException для фундаментальной ошибки
public void processArray(int[] arr) {
    if (arr == null) {
        throw new NullPointerException("Input array cannot be null"); // Стандартное RuntimeException
    }
    // ... логика обработки массива
}