空catch不安全但有时可接受，需满足明确良性信号、不影响逻辑、有日志监控等条件；推荐分层捕获+记录日志，优先用Optional或safe方法替代异常忽略。
直接捕获并空处理特定异常是否安全
不安全，但有时可接受。Java中用try-catch捕获异常后写空的catch块（即只写{}）确实能“忽略”异常，但会隐藏问题根源，导致调试困难、资源泄漏或状态不一致。
仅在以下情况可考虑空catch：
- 明确知道该异常是预期中的良性信号（如
InterruptedException在主动中断线程时） - 异常发生不影响后续逻辑，且已通过其他方式保障正确性（如尝试删除一个可能不存在的临时文件）
- 上层调用方已约定忽略该异常，且有完整日志或监控兜底
推荐做法：捕获后至少记录日志
忽略 ≠ 不留痕迹。哪怕不抛出、不重试，也应记录异常发生上下文，否则线上出问题时无从追溯。
示例（使用java.util.logging）：
立即学习“Java免费学习笔记（深入）”；
try {
Files.delete(Paths.get("/tmp/stale.lock"));
} catch (NoSuchFileException e) {
// 文件本来就没有，不报错，但记一条DEBUG日志
logger.fine("Lock file not found, skipping deletion: " + e.getMessage());
} catch (IOException e) {
// 其他IO异常不能忽略，需告警
logger.warning("Failed to delete lock file: " + e.toString());
}
关键点：
- 按异常类型分层处理，不要用
catch (Exception e)一锅端 -
NoSuchFileException继承自IOException，必须放在IOException之前捕获，否则会被父类吞掉 - 日志级别选
fine或debug，避免污染ERROR/WARN流
用Optional或返回码替代异常忽略
如果“异常发生”本质是业务逻辑中的正常分支（比如查数据库没找到记录），应避免抛异常，改用更语义化的方式表达“缺失”。
例如：
- 用
Optional<user></user>代替可能返回null或抛UserNotFoundException - 用布尔返回值+输出参数（如
boolean tryParse(String s, int[] out)）替代NumberFormatException - 工具类方法提供
safeXXX()变体，内部吞异常并返回默认值（如Integer.safeValueOf(String, int defaultValue)）
这样调用方无需写try-catch，语义清晰，也不会误吞不该忽略的异常。
静态检查工具能帮你发现危险的空catch
空catch块是代码异味（code smell），主流静态分析工具默认会告警：
-
SpotBugs：触发REC_CATCH_EXCEPTION或DE_MIGHT_IGNORE -
Checkstyle：规则EmptyCatchBlock可配置是否允许带注释的空块 -
PMD：规则EmptyCatchBlock，支持添加// ignore等白名单注释
建议在CI中启用这类检查，并要求所有空catch必须附带明确注释，说明为什么可以忽略、影响范围及是否有监控覆盖。
真正难的不是“怎么忽略”，而是判断“该不该忽略”——多数被忽略的异常，其实暴露的是设计缺陷或边界没想清楚。
