空catch块是异常吞噬的头号元凶，必须记录日志、抛出封装异常或真正兜底处理；禁用exception/throwable泛捕获；finally中避免覆盖异常；自定义异常须保留cause。
空catch块是异常吞噬的头号元凶
捕获异常后不做任何处理，甚至不记录日志，是最典型的异常吞噬。比如 try { riskyOperation(); } catch (Exception e) {} 这种写法会让问题彻底消失在系统中，后续排查时连线索都没有。
必须确保每个 catch 块至少做三件事之一：
- 记录完整堆栈（用 logger.error("描述性信息", e)，不是 e.printStackTrace()）
- 明确抛出封装后的业务异常（如 throw new BusinessException("操作失败", e)）
- 真正能兜底处理（例如重试、降级、返回默认值），且该逻辑本身不能抛新异常
不要用Exception或Throwable泛捕获
用 catch (Exception e) 会吞掉本该由上层处理的受检异常（如 IOException），也会意外捕获 RuntimeException 甚至 Error（如 OutOfMemoryError），后者根本不该被业务代码“消化”。
应遵循最小捕获原则：
- 只捕获你明确知道如何处理的具体异常类型（如 catch (SQLException e)）
- 避免捕获 Exception 或 Throwable，除非在顶层统一异常处理器中
- 对于 RuntimeException，多数情况应让它冒泡——它通常代表程序缺陷，掩盖反而延误修复
finally里别偷偷吃掉异常
finally 块中如果抛出异常，会覆盖 try 或 catch 中已发生的异常。例如关闭资源时发生 IOException，会导致原始业务异常完全丢失。
安全做法：
- 使用 try-with-resources（Java 7+），让编译器自动处理资源关闭和异常抑制（addSuppressed）
- 若必须手动关闭，应在 finally 中用 if (resource != null) try { resource.close(); } catch (IOException ignored) {}，且仅忽略关闭异常，绝不忽略业务异常
- 不要在 finally 中抛出新检查异常，也不要用 return 覆盖方法原有返回值
自定义异常别丢原始根因
包装异常时若只传消息不传 cause，就切断了调用链。比如 throw new ServiceException("数据库操作失败") 会让开发者失去堆栈和原始异常类型。
立即学习“Java免费学习笔记（深入）”；
正确方式：
- 所有自定义异常构造函数必须提供 Throwable cause 参数重载
- 抛出时始终带 cause：throw new ServiceException("用户未登录", e)
- 避免用字符串拼接掩盖异常来源（如 "failed: " + e.getMessage()），这会丢失堆栈和类型信息
异常吞噬的本质不是语法错误，而是对“谁该负责处理什么异常”的职责误判。最隐蔽的问题往往出现在日志被静默丢弃、资源关闭覆盖主异常、或自定义异常层层剥离堆栈的场景里。
