Java异常与日志需闭环协同：按错误类型（A/B/C码）精准抛/转异常，日志遵循“三不原则”（不中断、不泄密、不丢上下文），try-catch-finally分责执行，Spring Boot中用@ControllerAdvice统一收口并强制记录堆栈。
Java 异常处理与日志记录的综合练习，核心是把“异常怎么抛、怎么捕、怎么转义”和“日志怎么记、记什么、不记什么”真正串起来。不是分开练语法，而是按真实场景闭环操作——比如转账失败时，既要抛出语义明确的异常，又要打一条可定位、可归因、不干扰业务的日志。
一、明确异常类型与职责边界
先别急着写 try-catch，先问三个问题：
- 这个错误是调用方能改的吗？比如金额为负、账户为空 → 属于 用户端错误（A 开头错误码），应抛
IllegalArgumentException或自定义InvalidAmountException，并配错误码A0001 - 是本系统逻辑缺陷导致的吗？比如余额扣减后没校验是否为负 → 属于 本系统错误（B 开头错误码），应抛
IllegalStateException或自定义BalanceCorruptionException，错误码如B0101 - 是第三方接口超时或返回非法格式吗？→ 不直接抛
IOException或原始异常，而应 转义为本系统异常，保留原始堆栈，并在 error_message 中带上第三方错误码（如"C302: third-party timeout, original code=TIMEOUT_503"）
二、日志记录必须满足“三不原则”
即：不中断业务、不泄露敏感、不丢失上下文。实操要点：
-
不用字符串拼接日志：避免
log.debug("balance=" + account.getBalance() / amount)—— 除零会直接崩掉业务线程 -
优先用 SLF4J 参数化 + Supplier（SLF4J 2.0+）：
log.warn("Transfer failed for {}→{}, amount={}", () -> fromId, () -> toId, () -> amount)，仅当日志级别启用时才求值 -
关键字段单独提取为变量再记录：比如转账前先存
String traceId = MDC.get("traceId")，再统一打到每条日志里，而不是在每个 log 里重复调用MDC.get()
三、try-catch-finally 要有明确分工
不是所有代码都塞进 try 块，也不是所有资源都靠 finally 关。推荐结构：
立即学习“Java免费学习笔记（深入）”；
-
try 块只包真正可能出错的业务动作：如调用
thirdPartyService.pay()，不包括参数校验、对象构造等确定性操作 -
catch 块按异常语义分层捕获：先 catch
TimeoutException（转 C 错误），再 catchIllegalArgumentException（转 A 错误），最后 fallback 到Exception（兜底为 B 错误） - finally 只做无副作用清理：比如关闭数据库连接、释放锁；但不要在 finally 里调用可能抛新异常的方法（如再发一次 HTTP 请求），否则会掩盖主异常
四、Spring Boot 下的全局收口实践
用 @ControllerAdvice 统一转化异常为标准响应，同时触发日志：
- 每个
@ExceptionHandler方法里，先调用log.error("API[{}] failed, code={}, req={}", endpoint, errorCode, safeReqLog)，其中safeReqLog是已脱敏、已惰性求值的请求摘要 - 返回体固定含
error_code（如"B0203"）、message（面向开发者的精简描述）、request_id（用于日志串联） - 禁止在 handler 里吞掉原始异常 —— 至少要
log.error("", e)，确保堆栈进日志系统
