Когда стоит использовать проверяемые исключения (checked exceptions) при проектировании API в Java?

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

✅ Подходящие случаи:

1. Восстановимые ошибки — когда клиент может предпринять альтернативное действие (например, IOException при работе с файлами).
2. Ошибки бизнес-логики — которые являются частью контракта метода (например, InvalidCredentialsException).

❌ Неподходящие случаи:

1. Ошибки программирования (например, NullPointerException).
2. Системные сбои, которые клиент не может исправить (например, ошибки конфигурации).

Пример хорошего использования:

// Клиент ДОЛЖЕН обработать возможность отсутствия файла
public String readConfigFile(String path) throws IOException {
    return Files.readString(Paths.get(path));
}

Пример плохого использования (лучше unchecked):

// Ошибка валидации — обычно это ошибка программиста
public void validate(User user) throws ValidationException {
    if (user == null) {
        throw new ValidationException("User is null");
    }
}
// Лучше:
public void validate(User user) {
    if (user == null) {
        throw new IllegalArgumentException("User must not be null");
    }
}

Основные недостатки проверяемых исключений:

• Увеличивают шаблонный код (обязательные try-catch или throws).
• Нарушают принцип открытости/закрытости — изменение сигнатуры метода ломает обратную совместимость.
• Могут приводить к пустым блокам catch или прокидыванию исключений наверх без реальной обработки.

Рекомендация: Используйте unchecked исключения (RuntimeException) по умолчанию. Проверяемые исключения применяйте только для ошибок, которые являются ожидаемой частью бизнес-логики и требуют обязательной обработки клиентом.