Java/Scala异常捕获回调实现及RPC客户端迁移影响服务排查

问题背景 #

我们公司采用monorepo架构，大量服务依赖RPC客户端库1，该库会抛出一组运行时异常（记为S1）。现在计划将所有服务迁移至RPC客户端库2，但库2会抛出另一组运行时异常（记为S2）。我需要找出当RPC客户端异常语义从S1变更为S2时，会受到影响的服务列表。

已考虑的方案 #

• 方案1：逐一排查所有使用RPC客户端库1的服务代码，但服务数量多、异常处理逻辑复杂，该方案不具备可扩展性；
• 方案2：采用静态分析，但不确定静态分析能否检测到RPC库抛出的异常在调用栈多层上方被捕获的场景；
• 方案3：探索是否可为异常注册回调，在异常被捕获时触发回调，且回调能获取异常捕获位置信息。

回答 #

Java/Scala没有原生API支持为异常注册“捕获回调”，但可以通过以下手段实现类似效果，完美匹配你的场景需求：

1. 字节码增强（AspectJ/ByteBuddy）

这是最直接有效的方案，无需修改业务代码，能全局覆盖所有异常捕获场景：

• 实现思路：用切面工具定义切点，匹配所有捕获S1异常的catch块，在catch块执行前插入自定义回调逻辑。回调中可以通过Thread.currentThread().getStackTrace()解析出捕获位置的类、方法、行号信息，甚至关联到具体服务。
• 适配你的场景：在测试环境给所有服务织入这个切面，跑一遍全量测试或流量回放，就能收集到所有处理过S1异常的服务和代码位置。

2. Java Agent全局拦截

如果是monorepo批量服务检测，Java Agent更适合：

• 编写Agent，在类加载阶段修改所有包含catch块的类，插入异常捕获监听逻辑。只要捕获到S1中的异常，就记录捕获位置并上报。
• 优势：无需修改服务启动脚本以外的任何代码，能在JVM层面全局生效，适合大规模服务的批量检测。

3. 对静态分析的补充

你担心静态分析无法覆盖多层调用栈的捕获场景——其实部分成熟的静态分析工具（或自定义AST解析逻辑）是可以追踪异常抛出到捕获的链路的，但实现成本高，且容易漏判一些复杂场景（比如反射调用、动态代理）。相比之下，动态的字节码增强方案准确性更高。

针对迁移场景的最优建议 #

优先选择字节码增强+测试环境全量运行的方案：

1. 用AspectJ写一个切面，监听所有S1异常的catch操作，记录捕获位置对应的服务信息；
2. 在测试环境启动所有依赖RPC库1的服务，跑一遍核心业务流程或流量回放；
3. 收集所有触发过回调的服务，这些就是迁移到S2时需要重点适配的服务。

这种方式既避免了逐一排查的低效，又比静态分析更准确，能覆盖所有实际运行中会处理S1异常的场景。

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