空捕获在绝大多数场景下是严重反模式，但极少数情况可接受：资源清理中幂等操作失败、防御性校验试探分支、异步容错降级（需监控和WARN日志）、单元测试预期异常验证。
空捕获（即 catch (Exception e) { } 或仅写 catch (Exception e) {} 而不进行任何日志、响应或恢复操作）在绝大多数场景下是严重反模式，它会掩盖问题、阻碍排查、破坏可观测性。但极少数业务逻辑中，**“忽略异常变量本身”可被接受，前提是异常已被明确判定为无害、无副作用、且无需反馈——注意：这不等于“不处理异常”，而是“已处理完毕，变量无需再用”。**
资源清理类操作的 finally 替代路径
当 try 块中执行的是非关键性、幂等性资源释放动作（如关闭一个可能已关闭的流、注销一个可能未注册的监听器），且该动作失败不影响主流程时，可选择空 catch，但必须确保：
- 该操作本身不抛出影响后续逻辑的异常（如 IOException 不应中断事务提交）
- 已在 finally 中完成核心资源保障（如数据库连接池归还）
- 异常发生仅表示“资源已处于期望终态”，而非错误
示例：关闭一个 SocketChannel，若已断开则 close() 抛 ClosedChannelException，此时空 catch 是合理的，因通道状态已符合预期。
防御性校验中的静默失败
某些边界校验逻辑本质是“试探性判断”，失败即说明条件不成立，无需告警或干预：
- 尝试解析用户输入的日期字符串，多种格式都试一遍，某一种失败就跳过，不记录也不报错
- 检查系统属性是否为布尔值，若 parseBoolean() 抛 NumberFormatException，说明不是有效布尔字面量，直接返回默认 false 即可
- 反射获取某个可选字段，getDeclaredField() 找不到就跳过，不需提示“字段缺失”
关键点：异常仅用于控制流程分支，且所有分支均有明确定义的行为，无隐藏副作用。
异步/后台任务中的容错降级
在非关键路径的异步任务（如埋点上报、缓存预热、日志聚合）中，若网络超时或序列化失败，且重试无意义、失败不影响主业务，可空 catch 异常变量——但必须满足：
- 已有独立监控指标统计此类失败频次（如 Prometheus counter）
- 异常已通过统一日志框架以 WARN 级别记录（即使没打印 e.printStackTrace()，也至少输出简要上下文）
- 该任务设计上就是“尽力而为”，无强一致性要求
⚠️ 注意：此处“空捕获变量”不等于“不记录”，而是避免堆栈污染日志，用结构化日志替代原始异常对象。
单元测试中的预期异常验证
在 JUnit 4 的 @Test(expected = XXXException.class) 或 AssertJ 的 assertThatCode(...).isInstanceOf(...) 场景下，try-catch 仅用于断言，捕获后无需操作变量：
- 测试目标就是确认异常被抛出，而非处理它
- catch 块内只需调用
fail("Expected exception not thrown")或类似断言失败逻辑 - 异常变量 e 本身不参与业务判断，故无需使用
这种写法本质是测试框架约束下的语法需要，不属于生产代码逻辑。
