try-catch-finally 是微服务中保障调用韧性与可观测性的关键机制，涉及异常分级处理、资源清理、链路追踪及统一错误响应。
在微服务架构中，try-catch-finally 不是单纯语法结构，而是保障服务间调用韧性与可观测性的关键机制。它直接关系到错误是否被掩盖、资源是否泄漏、链路是否中断、日志是否可追溯。
网络调用失败时的兜底与重试控制
远程调用（如 HTTP、gRPC、Dubbo）极易因网络抖动、超时或目标服务不可用而抛出异常（如 ConnectException、SocketTimeoutException、FeignException）。此时应在 try 中发起调用，catch 精确捕获可重试异常，并结合熔断器（如 Sentinel 或 Resilience4j）做分级处理：
- 对 IOException 子类（如连接超时）可尝试有限重试
- 对 4xx 响应异常（如 400/401）通常不重试，需记录并快速失败
- finally 中不执行业务逻辑，但可统一记录“调用耗时”“是否成功”，供监控埋点
分布式事务中的资源清理与状态补偿
当使用 Saga 模式或本地消息表实现最终一致性时，try 块执行主操作（如扣减库存），catch 捕获失败后触发补偿动作（如发消息回滚订单），而 finally 则确保关键上下文不丢失：
- 关闭数据库连接、HTTP 客户端连接池连接等资源（推荐优先用 try-with-resources）
- 清空 ThreadLocal 中的请求上下文（如 traceId、tenantId），避免线程复用导致透传污染
- 不要在 finally 中修改业务状态或调用远程服务——它只做确定性清理
跨服务链路追踪与异常透传
微服务调用链中，异常需携带 traceId 传递给上游，同时避免敏感信息泄露。catch 块应做两件事：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 用 MDC（Mapped Diagnostic Context）将 traceId 注入日志，再打印异常堆栈（e.printStackTrace() 不推荐，改用 SLF4J 的 logger.error("xxx", e)）
- 若需向上游返回错误，应封装为标准响应体（如
{ "code": 500, "msg": "下单服务调用库存失败" }），而非直接抛出原始异常 - 避免在 catch 中吞掉异常（空 catch）或仅 log.info —— 错误级别日志必须是 error
自定义异常配合网关统一错误响应
建议定义分层异常体系，例如：
- BizException（继承 RuntimeException）：业务规则拒绝，如“余额不足”，网关统一转为 400
- RemoteException（继承 Exception）：下游服务不可达，需重试或降级，网关转为 503
- AuthException：鉴权失败，网关拦截并返回 401
这些异常在 controller 层由全局异常处理器（@ControllerAdvice）捕获，屏蔽堆栈细节，输出用户友好的 message，并设置对应 HTTP 状态码——这才是 finally 之外更上层的“善后”。
