不建议主动捕获 NullPointerException，因其反映逻辑缺陷，掩盖问题且违反快速失败原则；应通过Objects.requireNonNull()、Optional、静态检查工具等预防性手段规避。
不建议主动捕获 NullPointerException（NPE），它属于运行时异常（RuntimeException 的子类），设计上应通过预防而非捕获来处理。
为什么不该用 try-catch 捕获 NullPointerException
空指针异常通常反映程序逻辑缺陷，比如忘记初始化对象、方法返回 null 后直接调用其方法等。捕获它只是掩盖问题，不能修复根本原因，还可能让错误延迟暴露，增加调试难度。
- 违反“快速失败”原则：应在出错点立即发现问题，而不是继续执行到后续不可预知的状态
- 掩盖真实 bug：比如本该返回非 null 对象的方法返回了 null，捕获 NPE 后可能误以为操作成功
- 性能无意义：NPE 是编程错误，不是可恢复的业务异常，捕获后通常也无法合理恢复流程
更可靠的替代方案
用防御性编程提前规避 NPE，让代码更健壮、可读性更高：
- 使用 Objects.requireNonNull()：在方法入口校验关键参数是否为 null，抛出带提示信息的 NPE，便于定位
-
使用 Optional 类型：明确表达“可能为空”的语义，强制调用方处理空值分支（如
Optional.ofNullable(obj).map(...).orElse(...)） -
启用编译期检查工具：如 IntelliJ 的 nullability 注解（
@NotNull/@Nullable）、SpotBugs、或 Lombok 的@NonNull自动生成校验 - 约定 API 行为：文档或接口规范中明确哪些方法/字段绝不返回 null，哪些可能返回，统一团队认知
极少数允许捕获 NPE 的场景
仅限于你完全无法控制的外部代码（如老旧第三方库、反射调用、动态生成字节码等），且确认该异常是已知、可控、可安全忽略或降级处理的副作用时，才考虑捕获：
立即学习“Java免费学习笔记（深入）”；
- 必须加上清晰注释，说明为何此处捕获是合理且必要的
- 不要裸 catch（即不写具体异常类型），也不要用
catch (Exception e) - 捕获后应记录日志，并提供明确 fallback 行为（如返回默认值、跳过当前项等）
示例（不推荐日常使用，仅作说明）：
try {
result = externalLib.process(data); // 可能因内部 bug 抛 NPE
} catch (NullPointerException e) {
logger.warn("externalLib.process() threw NPE, using fallback", e);
result = DEFAULT_RESULT;
}
总结
捕获 NullPointerException 不是解决空指针问题的正确方式。重点应放在编写更严谨的代码：初始化必填对象、校验入参、善用 Optional、借助工具和规范约束 null 的传播。只有在面对不可控的外部行为且有充分理由时，才谨慎捕获并妥善处理。
