Что проверяет вопрос про @Retryable и recover-метод

Аннотация @Retryable из Spring Retry перехватывает вызов через proxy — тот же механизм AOP, что у @Transactional и @Async. Значит self-invocation внутри одного бина её не активирует, а maxAttempts и backoff настраиваются прямо в аннотации, без ручного цикла retry в коде.

Вопрос обычно продолжают так: что произойдёт, если исчерпаны все попытки. Ответ — вызывается метод, помеченный @Recover, если его сигнатура совпадает с типом исключения и возвращаемым значением исходного метода. Если совпадения нет, exception просто улетает вызывающему коду.

@Retryable( retryFor = SQLException.class, maxAttempts = 3, backoff = @Backoff(delay = 200) ) public Order loadOrder(long id) { return repository.findById(id); }

@Recover public Order recover( SQLException e, long id) { return Order.empty(); }

Ловушка — несколько методов с @Recover под разные типы исключений в одном классе. Spring выбирает по наиболее специфичному типу, совпадающему с исключением из retry, но если сигнатуры пересекаются или отсутствует совпадение по параметрам после исключения — при старте контекста будет ошибка конфигурации, не runtime-сюрприз.

Финал: @Retryable решает проблему временных сбоев, а не логических ошибок — retryFor должен указывать конкретные исключения, а не Exception.class целиком.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки