java 中不应捕获 nullpointerexception 等系统级未受检异常，因其代表逻辑错误，须在开发阶段暴露修复；应通过 optional、参数校验、静态分析等预防措施避免 npe 发生。
Java 中无法也不应“优雅捕获” NullPointerException（NPE）或其它系统级未受检异常（如 ArrayIndexOutOfBoundsException、ClassCastException 等）。这不是设计缺陷，而是 Java 的明确约定：这些异常代表程序逻辑错误，应在开发阶段暴露并修复，而非运行时兜底处理。
为什么不该 catch NullPointerException
捕获 NPE 会掩盖真正的问题根源：
- NPE 表示你本该校验却没校验的对象为
null，比如调用user.getName().length()前未确认user非空； - 一旦用
try-catch捕获并“静默吞掉”或仅打日志，后续行为可能更隐蔽（如返回默认值、跳过关键步骤），导致数据错乱或状态不一致； - 它让代码变得不可靠——同一段逻辑在不同输入下可能成功或失败，且失败原因被隐藏。
真正优雅的做法：预防优于捕获
把精力放在避免 NPE 发生，而不是事后处理：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
-
使用 Optional 明确表达“可能为空”的语义，例如：
Optional<user> findUser(Long id)</user>，调用方必须显式处理空情况； -
尽早校验参数，在方法入口用
Objects.requireNonNull(obj, "obj must not be null")快速失败； - 利用现代 IDE 和静态分析工具（如 IntelliJ 的 nullability 注解、SpotBugs、Error Prone），在编码阶段标出潜在空指针；
-
合理设计 API，避免返回
null，优先返回空集合、空字符串或Optional； -
启用 JDK 14+ 的空指针增强诊断（
-XX:+ShowCodeDetailsInExceptionMessages），让 NPE 堆栈直接指出哪一行、哪个变量为null。
系统级未受检异常的正确应对策略
像 IllegalArgumentException、IllegalStateException、ConcurrentModificationException 等，同样属于编程错误信号：
- 它们不是“意外”，而是契约被破坏的证据（例如传入负数给只接受正数的方法）；
- 全局异常处理器（如 Spring 的
@ControllerAdvice）可统一记录和响应，但目的不是“恢复”，而是快速定位 + 友好提示 + 防止敏感信息泄露； - 绝不应在业务逻辑中用
catch (RuntimeException e)吞掉异常并继续执行——这等于纵容 bug 存活。
什么情况下可以 catch RuntimeException？
极少数边界场景，前提是：你完全理解风险，且有明确、安全的降级方案：
- 集成第三方 SDK，其文档明确说明某方法会抛出特定
RuntimeException作为正常流程的一部分（罕见）； - 解析外部不可信输入（如用户上传的 JSON），用
JsonProcessingException（虽是检查异常，但思路类似）做格式校验，此时捕获是为了返回清晰错误码，而非掩盖问题； - 在严格隔离的沙箱环境里执行动态脚本，需防止脚本崩溃整个服务——但这属于架构层防护，不是业务代码的常规做法。
不复杂但容易忽略：写出健壮的 Java 代码，核心不是写更多 catch，而是用类型、注解、工具和习惯，在编译期和测试期就把空和非法状态挡在外面。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
