RuntimeException 不强制捕获但可捕获，因其属非检查异常，编译器不强制处理；实际中应在API入口、批处理等边界处有针对性捕获，避免掩盖bug，优先修复源头而非掩盖异常。
RuntimeException 不需要强制捕获，但可以捕获——关键在于你是否要干预其默认终止行为。
为什么 try-catch RuntimeException 是合法但非强制的
Java 将 RuntimeException 及其子类（如 NullPointerException、ArrayIndexOutOfBoundsException）归为「非检查异常（unchecked exception）」。编译器不强制你用 try-catch 或 throws 声明它们。
- 这不表示它们不重要，而是设计上认为这类异常通常源于程序逻辑错误，应通过修复代码而非掩盖异常来解决
- 但实际开发中，你可能需要在特定边界处捕获，比如对外暴露的 API 入口、批处理任务循环体、或集成第三方 SDK 时的兜底防护
- 直接
catch (Exception e)会一并捕获RuntimeException，但容易掩盖真正该修复的 bug，不推荐无差别使用
捕获特定 RuntimeException 的典型场景与写法
明确捕获某类运行时异常，是为了做有针对性的恢复或记录，而不是吞掉它。
- 解析外部数据时预防
NumberFormatException：String input = request.getParameter("age"); int age; try { age = Integer.parseInt(input); } catch (NumberFormatException e) { log.warn("非法年龄格式: {}", input); age = 0; // 提供默认值 } - 访问集合前不确定索引有效性，捕获
IndexOutOfBoundsException（但更推荐先用list.size()判断） - 调用反射方法时捕获
IllegalAccessException或InvocationTargetException—— 它们虽是RuntimeException子类，但属于框架/反射层常见可预期异常
不要在 finally 中抛出 RuntimeException
finally 块里如果抛出新的 RuntimeException，会覆盖 try 或 catch 中已发生的异常，导致原始错误丢失。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 例如：在
try中发生NullPointerException，而finally调用一个空对象的close()导致又抛NullPointerException，前者将被静默吞掉 - 正确做法是确保
finally中的操作是安全的，或使用 try-with-resources（对AutoCloseable类型） - 若必须手动关闭资源，先判空再调用：
if (resource != null) { try { resource.close(); } catch (IOException e) { log.error("关闭 resource 失败", e); } }
全局异常处理器比到处 try-catch 更适合统一处理 RuntimeException
尤其在 Spring Web 环境中，用 @ControllerAdvice + @ExceptionHandler 拦截未被捕获的 RuntimeException，比在每个 service 方法里加 try-catch 更干净。
- 避免业务代码被异常处理逻辑污染
- 能统一返回结构（如标准错误码、日志脱敏、告警触发）
- 注意：
@ExceptionHandler默认只对当前 controller 生效；加@ControllerAdvice才全局生效 - 慎捕
Throwable—— 它包含Error（如OutOfMemoryError），这类错误不应尝试恢复
真正难的不是“能不能捕”，而是“该不该捕”和“在哪一层捕”。多数 RuntimeException 暴露的是代码缺陷，优先修复源头；只有当异常来自不可控边界（用户输入、网络响应、遗留系统返回），才考虑捕获并转化成可控行为。
