不需要。运行时异常（如NullPointerException、ArrayIndexOutOfBoundsException）属unchecked exception，编译器不强制捕获，但未处理会导致线程中断、响应失败甚至崩溃；应依可预判性与业务恢复路径决定是否显式处理。
Java中运行时异常是否必须用try-catch捕获？
不需要。运行时异常（RuntimeException及其子类，如NullPointerException、ArrayIndexOutOfBoundsException）属于**unchecked exception**，编译器不强制要求捕获或声明。但不捕获不等于该忽略——未处理的运行时异常会导致当前线程中断、堆栈打印、服务响应失败甚至进程崩溃。
常见误判是“既然不用写try-catch，那就不理它”。实际线上系统中，多数5xx错误和空指针告警都源于对运行时异常的放任。
哪些运行时异常值得主动捕获并处理？
关键看两点：是否可预判、是否有业务恢复路径。不能一概而论“全捕获”，也不能“全抛出”。以下场景建议显式处理：
-
NumberFormatException：用户输入文本转数字失败，应返回友好提示而非500 -
IllegalArgumentException：参数校验失败，可在Controller层拦截并统一返回400 -
ConcurrentModificationException：多线程遍历+修改集合，需改用CopyOnWriteArrayList或加锁，而非仅try-catch -
OptimisticLockException（JPA）：版本冲突，适合重试或提示“数据已被他人修改”
注意：NullPointerException一般不应捕获——它反映代码逻辑缺陷，应通过Objects.requireNonNull()、Optional或提前判空修复，而非兜底catch。
立即学习“Java免费学习笔记（深入）”；
如何避免try-catch掩盖真实问题？
空catch块、只打日志不抛出、吞掉异常后返回默认值，是三大高危操作。例如：
try {
return userService.findById(id);
} catch (RuntimeException e) {
log.warn("findById failed", e); // ❌ 无后续动作，调用方拿到null，问题延后爆发
return null;
}
正确做法包括：
- 捕获后做**有语义的补偿**：如降级返回缓存数据、触发异步修复任务
- 记录足够上下文：
log.error("fail to load user {}, traceId={}", id, traceId, e) - 必要时包装再抛出：
throw new ServiceException("用户查询失败", e)，保留原始栈信息 - 避免在finally里吞异常：若
close()也抛异常，会覆盖主逻辑异常
全局异常处理与日志链路的配合要点
Spring Boot常用@ControllerAdvice + @ExceptionHandler做统一处理，但容易忽略两点：
- 不同异常类型要分层响应：对
IllegalArgumentException返回400，对ServiceException返回500，对AccessDeniedException返回403 - 日志必须携带traceId（如用MDC），否则无法关联请求链路；否则你只能看到“空指针”，却找不到是哪个接口、哪个参数触发的
- 不要在全局处理器里吃掉所有
RuntimeException：像OutOfMemoryError这种JVM级错误，捕获后继续运行可能引发更严重状态不一致
最常被跳过的细节是：全局异常处理器默认不处理过滤器（Filter）和拦截器（Interceptor）中的异常，那些地方仍需单独try-catch。
