空捕获会吞掉异常所有线索，导致静默失败；finally 中 return 会覆盖异常；包装 checked exception 需保留语义；日志必须用结构化模板+异常对象，禁用 printstacktrace。
catch (Exception e) { } 这种空捕获到底错在哪
它不是“没写代码”，而是主动屏蔽了所有线索。JVM 抛出异常时附带的堆栈、异常类型、触发上下文，全被这一行吞掉了。
常见错误现象：NullPointerException 或 IOException 发生后程序静默失败，日志里查不到任何痕迹，下游调用超时才暴露问题。
- 永远不要捕获
Exception或Throwable后不处理；只捕获你明确知道如何应对的异常类型，比如NumberFormatException用于解析失败兜底 - 即使要“忽略”，也得加日志：
logger.debug("Ignoring expected format issue", e)，且必须带异常对象，不能只打字符串 -
catch (RuntimeException e)同样危险——它会吃掉IllegalArgumentException这类本该快速暴露逻辑错误的异常
在 finally 里写 return 导致异常丢失
这是 Java 字节码层面的陷阱：finally 中的 return 会直接终结方法执行，覆盖 try/catch 块中已抛出的异常。
使用场景：资源关闭 + 异常传播并存时（如数据库连接关闭失败，但业务逻辑已抛出 SQLException）。
立即学习“Java免费学习笔记（深入）”；
- 绝对避免在
finally块中写return或抛异常 - 资源关闭统一用 try-with-resources，它能保证异常压制（
addSuppressed）而非覆盖 - 如果必须手动 close，把 close 放在 try 块内，并单独 catch
IOException等检查型异常，不 throw 不 return
把 checked exception 包装成 RuntimeException 后乱扔
用 new RuntimeException(e) “简化”签名，本质是把编译器强制你面对的问题，推给调用方 runtime 承担——而调用方根本不知道这个 RuntimeException 其实源自 SQLException。
性能/兼容性影响：掩盖异常语义，导致上层无法区分可恢复错误（如网络抖动）和不可恢复错误（如配置缺失）。
- 只有当你明确知道调用链所有环节都无需区分异常类型时，才考虑包装；否则优先保留原始类型
- 若必须转换，用带 cause 的构造函数：
throw new ServiceException("DB query failed", e)，并确保自定义异常继承RuntimeException或保留 checked 属性 - Spring 项目中，更推荐用
@ControllerAdvice统一转换，而不是在 service 层随意包装
log.error("出错了") + e.printStackTrace()
e.printStackTrace() 输出到 System.err，脱离日志框架管理，既无法按级别过滤，也无法路由到 ELK 或告警系统；而 "出错了" 这种日志等于没写。
常见错误现象：线上出问题后，grep 日志搜不到关键词，只能靠运维翻控制台输出。
- 一律用 SLF4J 或 Log4j2 的
logger.error("Failed to process order {}", orderId, e)—— 消息模板 + 参数 + 异常对象三者缺一不可 - 避免在日志消息里拼接异常信息：
e.toString()或e.getMessage()不能替代异常对象本身 - 敏感字段（如用户 ID、金额）不要直接打在日志里；需脱敏或转为 traceId 关联上下文
