没用——除非明确知道哪一行可能抛npe且本不该为null；npe是可预防的逻辑缺陷，应通过参数校验、optional、静态检查等源头预防，而非依赖try-catch掩盖问题。
NullPointerException 出现时 try catch 有用吗？
没用——除非你明确知道哪一行可能抛出 NullPointerException，且那个位置本就不该为 null。Java 的 NullPointerException 是运行时异常（RuntimeException 子类），编译器不强制捕获，但盲目加 try catch 只会掩盖问题根源。
-
try catch不能替代空值检查，它只是兜底手段 - 捕获后若只打印日志或吞掉异常，后续逻辑可能因变量仍为
null而继续崩溃 - 真正该做的是：在使用前判断，或用
Objects.requireNonNull()、Optional主动防御
什么时候该用 try catch 处理 NullPointerException？
极少数场景下，你依赖的外部代码（比如第三方 SDK、反射调用、动态加载的类）行为不可控，且你无法修改其源码，这时才考虑捕获：
- 调用一个已知可能返回
null的遗留方法，且文档没说明，又没法改它 - 使用
Class.forName().getMethod().invoke()时，参数或返回值意外为null - 解析 JSON 或 XML 后的字段未做校验，而上游数据质量差，临时容错
示例（仅作说明，非推荐写法）：
try {
String name = user.getName(); // user 可能为 null，但此处业务允许跳过
process(name);
} catch (NullPointerException e) {
log.warn("user or name is null, skip processing", e);
}
⚠️ 注意：这种写法必须配日志+明确业务语义（如“跳过”），不能无条件吞异常。
比 try catch 更靠谱的预防方式
真正降低 NullPointerException 的做法，是把检查提前到使用前：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 用
Objects.requireNonNull(obj, "obj must not be null")在入口处快速失败 - 方法参数用
@NonNull注解（配合 IDE 或 Checker Framework 静态检查） - 返回集合/列表优先用
Collections.emptyList()而非null - 对可能为空的引用，用
Optional.ofNullable(obj).map(...).orElse(...)显式表达意图
例如：
public void setName(String name) {
this.name = Objects.requireNonNull(name, "name cannot be null");
}
这样异常堆栈指向问题源头（构造/赋值处），而不是下游某个 .toString() 调用点。
IDE 和静态分析工具怎么帮上忙？
现代开发中，靠人肉检查容易漏，要借工具：
- IntelliJ IDEA 默认开启
Constant conditions & exceptions检查，能标出明显空指针风险行 - 启用
Nullability annotations（如@Nullable/@NotNull），配合编译期警告 - 在 Maven 中引入
checkerframework，用@NonNull做类型级校验 - SonarQube 规则
S2259专门检测 “dereferenced expression might be null”
这些不是锦上添花，而是把空指针问题从运行时提前到编码阶段暴露。
空指针的本质从来不是“怎么 catch”，而是“谁该负责确保不为 null”——接口设计者、调用者、还是中间适配层？这个问题没想清楚，加再多 try catch 也只是在流沙上砌墙。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
