Почему Lombok @SneakyThrows опасен и меняет контракт

Аннотация @SneakyThrows в Lombok позволяет бросать checked-исключения без объявления их в сигнатуре метода и без использования блока try/catch. Внешне это выглядит как удобное сокращение кода, однако фактически приводит к изменению контракта метода и нарушает корректность обработки ошибок вызывающей стороной.

В этой статье разберем, как именно @SneakyThrows влияет на поведение программы, и почему его использование в публичных API может быть нежелательным.

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

Что делает @SneakyThrows

@SneakyThrows выбрасывает исключение as is, но обходя проверку компилятора на обязательное объявление checked-исключений. Пример:

@SneakyThrows
public void write(Path path) {
    Files.write(path, new byte[]{1, 2, 3}); // IOException
}

Метод не объявляет throws IOException, не содержит блок try/catch и вызывающий код не обязан ловить исключение. Но в рантайме исключение все равно будет брошено.

Почему это нарушает контракт метода

Контракт метода нарушается: исключение есть, но о нем никто не знает.

Исключение перестает быть частью API

Метод, который раньше имел явный контракт:

public void write(Path path) throws IOException

после применения @SneakyThrows превращается в:

public void write(Path path)

Со стороны вызывающего кода:

• IDE не подсказывает, что метод может завершиться ошибкой;
• Невозможно понять семантику исключений без чтения реализации;
• Контракт API становится неявным и непредсказуемым.

Исключение меняет классификацию

Поскольку @SneakyThrows выбрасывает исключение без объявления, checked-исключение перестает быть checked, вызывающая сторона рассматривает его как непредвиденное. Это влияет на логику обработки ошибок, особенно если вызывающий код ожидает определенное исключение.

Пример: вызывающий код ожидает конкретное исключение

Пусть есть метод, который должен бросать IOException:

public void save(Path path) throws IOException {
    write(path);
}

И вызывающий код корректно его обрабатывает:

try {
    service.save(path);
} catch (IOException e) {
    // ожидаемая ветка: повторная попытка или fallback
}

Теперь заменим реализацию write на вариант с @SneakyThrows:

@SneakyThrows
public void write(Path path) {
    Files.write(path, new byte[]{1});
}

Что изменилось? write() по-прежнему бросает IOException в рантайме, но сигнатура метода не содержит throws IOException, IDE и компилятор не считают этот метод источником IOException, вызывающий код не обязан и не ожидает обрабатывать это исключение.

Исключение в рантайме остается тем же (IOException), но вызывающий код не будет писать catch (IOException), потому что сигнатура метода не сигнализирует о checked-ошибке.

Если write() бросит IOException, а вызывающий код не поставил обработчик catch (IOException), то исключение не будет поймано в ожидаемой ветке, не сработает fallback-логика, ошибка поднимется выше по стеку как необработанная (хотя все еще IOException).

Дополнительные риски

Нарушение совместимости при обновлениях API

С точки зрения JVM и байткода, удаление объявления throws не нарушает бинарную совместимость. Клиентский код продолжит компилироваться и выполняться. Однако такая операция нарушает логическую совместимость API — то есть спецификацию поведения, на которую рассчитывает вызывающий код.

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

Ухудшение читаемости и предсказуемости

Использование @SneakyThrows снижает прозрачность кода, потому что исключения перестают быть явной частью API. Это влияет сразу на несколько аспектов: понимание поведения, ревью, поддержку и анализ системы.

Неправильная маршрутизация исключений в фреймворках

Во многих фреймворках и инфраструктурных библиотеках исключения используются как механизм управления потоком выполнения. Семантика checked и unchecked исключений определяет:

• Как будет продолжена обработка запроса;
• Будет ли выполнен rollback транзакции;
• Попадет ли ошибка в retry-механизм;
• Какое состояние будет зафиксировано;
• Какой статус сформируется в протоколе или сетевом ответе.

Аннотация @SneakyThrows нарушает эти правила, поскольку маскирует checked-исключения под необъявленные, что меняет их трактовку фреймворком.

Большинство платформ используют тип исключения как элемент бизнес-логики. Они различают:

• Ошибки ввода-вывода;
• Оошибки бизнес-валидации;
• Ошибки сериализации;
• Сетевые сбои;
• Системные ошибки.

@SneakyThrows делает эту классификацию неявной. Ниже рассмотрены типичные случаи.

Несоответствие ожидаемому статусу ошибки

Пример для JAX-RS / Jakarta REST:

Обычно обработчик ошибок строится так:

try {
    service.process();
} catch (ValidationException e) {
    return Response.status(400).build();
} catch (IOException e) {
    return Response.status(503).build(); // временная недоступность
}

Если метод process() использует @SneakyThrows, то IOException больше не является частью API и может рассматриваться как необработанный RuntimeException, и попадет в общий обработчик, например 500 Internal Server Error.

Таким образом:

Было	Стало
IOException → 503	IOException (скрытая) → 500

Это нарушает семантику статусов.

Ошибочный rollback транзакции

В Spring транзакционное поведение зависит от того, перехватывает ли вызывающий код исключение:

• RuntimeException и Error всегда приводят к rollback;
• Checked-исключения не вызывают rollback, если вызывающий код их ожидает и обрабатывает.

Без @SneakyThrows вызов выглядит предсказуемо:

@Transactional
public void store() throws IOException {
    writeToFile(); // может бросить IOException
}

Сигнатура метода явно сообщает, что возможен IOException, и вызывающая сторона обязана его обработать. Обработанный checked-exception не приводит к rollback.

С @SneakyThrows сигнатура скрывает checked-исключение:

@SneakyThrows
public void writeToFile() {
    Files.write(path, data); // бросает IOException
}

Вызывающий код больше не знает, что метод может завершиться IOException:

@Transactional
public void store() {
    writeToFile(); // исключение не ожидается и не перехватывается
}

В результате IOException прорывается вверх как неперехваченное исключение. Spring трактует неперехваченную ошибку как основание для отката транзакции, и выполняет rollback, хотя по типу это все еще checked-exception.

Неверная работа retry-механизмов

В системах, где есть механизм повторных попыток (например, Spring Retry, сетевые кластеры, брокеры задач), решение о повторе часто основывается на типе исключения.

Например:

@Retryable(value = IOException.class)
public void send() throws IOException {
    channel.write(data);
}

Если @SneakyThrows скрывает IOException, то retry не сработает, исключение будет интерпретировано как непредвиденная ошибка и повторная попытка отправки не произойдет.

Нарушение обработки ошибок сериализации/десериализации

В библиотеках типа Jackson, JAXB, JSON-B, XML-Serializers checked-исключения (например, JsonProcessingException) сигнализируют:

• Неправильный формат входных данных;
• Невозможность обработки запроса.

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

Нарушение протокольной логики

Во многих интеграционных протоколах (REST, SOAP, RPC, messaging) checked-исключения используются для ожидаемых сбоев, runtime — для непредвиденных.

@SneakyThrows неявно переносит ошибку из одной категории в другую.

Итого:

Тип ошибки	Значение в протоколе	Поведение после @SneakyThrows
Checked (I/O, network)	временная ошибка;	рассматривается как системная
	операция может быть повторена	(непредвиденная)
Runtime (NPE, IllegalState)	дефект кода	смешивается с I/O ошибкой
		и трактуется как ожидаемая

Это ухудшает предсказуемость поведения интеграции.

Рекомендации по использованию

@SneakyThrows допустим только в узкой области. Использовать можно во внутренних private-методах, которые вызываются из вышестоящего try/catch, когда исключение все равно обрабатывается на границе уровня.

Не стоит использовать:

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