捕获异常后必须记录、重抛或返回失败信号，禁用空catch；checked异常用于调用方可响应的场景，unchecked用于编程错误；资源关闭优先用try-with-resources；重抛异常须保留cause。
捕获异常后不抛出或记录，程序会静默失败
Java中用 try-catch 捕获异常却只写个空 catch 块，是最常见也最危险的做法。异常被吞掉后，调用方完全感知不到错误，后续逻辑可能基于错误状态继续执行，导致数据不一致或更隐蔽的崩溃。
必须至少做以下之一：
- 记录日志：用
logger.error("处理用户订单失败", e)，确保堆栈完整 - 转换并重抛：如将
IOException包装为业务异常new OrderProcessingException("文件读取异常", e) - 返回明确的失败信号：比如方法返回
Optional.empty()或自定义结果类中的isSuccess() == false
何时该用 checked 异常，何时用 unchecked
Exception 及其子类（除 RuntimeException）是 checked 异常，编译器强制你处理；RuntimeException 及其子类是 unchecked，可选择性捕获。
判断依据不是“能不能恢复”，而是“调用方是否能合理响应”：
立即学习“Java免费学习笔记（深入）”；
- 用 checked：如
SQLException、IOException—— 调用方很可能需要重试、切换数据源或提示用户“网络异常，请稍后” - 用 unchecked：如
NullPointerException、IllegalArgumentException—— 属于编程错误，应修复代码，而非现场捕获处理 - 自定义异常优先继承
RuntimeException，除非你明确要求所有调用链都声明处理逻辑
finally 中资源关闭的陷阱：close() 本身可能抛异常
在 finally 块里手动调用 resource.close()，如果 close() 抛出异常（比如流已关闭或 I/O 错误），它会覆盖 try 块中原本的异常，导致真正的问题被掩盖。
正确做法只有两个：
- 使用 try-with-resources（推荐）：
try (FileInputStream fis = new FileInputStream("data.txt"); BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) { return reader.readLine(); } // 自动按声明逆序 close，且压制 close 异常 - 若必须手动关闭，对每个
close()做独立try-catch，且不抛出，仅记录：if (conn != null) { try { conn.close(); } catch (SQLException e) { logger.warn("关闭数据库连接失败", e); } }
不要在 catch 里吞掉异常的 cause
重新抛出异常时，直接 throw new ServiceException("下单失败") 会丢失原始堆栈，排查时只能看到新异常，看不到底层是 JDBC timeout 还是 Redis 连接拒绝。
务必保留原始异常作为 cause：
- 构造时传入：
throw new ServiceException("下单失败", e) - 或者用
initCause(e)（仅限未在构造中设置过 cause 的异常） - 日志打印也要用
logger.error(msg, e)形式，而不是logger.error(msg + e)
多层服务调用中，异常链断裂比空 catch 更难定位——它让你以为问题出在上层，实际根因早被抹掉了。
