Spring @Retryable捕获方法内BadGatewayException触发重试，是否为正常逻辑？

核心原因 #

你遇到的现象是Spring @Retryable的默认异常匹配逻辑和你的实现疏漏共同导致的：

• 首先你大概率在实际代码中抛出包装异常RuntimeException时，将原始BadGatewayException作为cause传入了构造方法，写法类似：

catch(e: Exception) {
    // 注意第二个参数传入了原始异常
    throw RuntimeException("a system error has occurred", e)
}

• Spring @Retryable默认匹配异常时会递归遍历异常的整个因果链，只要因果链中存在include配置的异常类型，就会触发重试。哪怕最终抛出的是包装后的RuntimeException，只要其cause链中包含BadGatewayException，就会命中重试规则。这和你观察到的"重试耗尽后才抛出包装后的RuntimeException"的流程完全吻合。

如果你的handle方法实际为private权限但重试依然生效，说明你使用了AspectJ静态织入来启用重试切面，该模式支持切入非public方法，不影响异常匹配逻辑。

修复方案 #

如果你不需要对包装后的异常触发重试，可选择以下任意一种方案：

1. 配置@Retryable仅匹配顶层抛出的异常，不遍历因果链，修改注解配置为：

@Retryable(
    include = [BadGatewayException::class],
    // 仅当顶层抛出的异常为BadGatewayException时才重试，替换为你自己的类全限定名
    exceptionExpression = "#root instanceof T(com.yourpackage.BadGatewayException)"
)

2. 调整异常处理逻辑，在catch块中单独处理BadGatewayException，不需要包装直接抛出，其他异常才包装为RuntimeException：

catch(e: BadGatewayException) {
    throw e
}
catch(e: Exception) {
    throw RuntimeException("a system error has occurred", e)
}

这种方案更符合@Retryable的设计使用习惯，业务异常直接抛出给切面处理，系统异常统一包装。

内容的提问来源于stack exchange，提问作者Soo