非受检异常是声明编程错误需修复的契约信号，仅用于参数语义违规、非法状态调用及自定义业务规则错误；文档必须用肯定语气明确异常原因、责任归属与修复要求，禁用“建议”等弱化表述。
非受检异常不是“随便抛”的免责条款，而是有明确使用契约的信号机制——它声明的是“这是编程错误，应修复而非捕获”。配套的文档注释必须清晰传达这个意图，否则契约就失效了。
使用契约：什么该抛，什么不该抛
非受检异常只适用于暴露和修正可控的内部逻辑缺陷：
- 参数明显违反语义（如
age = -5、name = null且业务不允许）→ 抛IllegalArgumentException或NullPointerException - 对象处于非法状态时被调用（如已关闭的流再读取、未初始化的服务执行操作）→ 抛
IllegalStateException - 自定义业务规则类错误（如订单在“已发货”状态下仍尝试取消）→ 继承
RuntimeException，命名体现违规性质（如InvalidOrderStateRuntimeException） - 用户输入校验失败、第三方服务超时、余额不足等预期业务分支 → 不适用非受检异常，应走返回值或受检异常
文档注释必须说明“为什么是 RuntimeException”
Javadoc 不仅要写“抛出什么异常”，更要解释“为何抛这个异常”，否则调用方无法判断是否属于 bug：
- 在
@throws IllegalArgumentException后补充说明：「当userId为null或负数时抛出，表明上游调用未履行必填参数契约」 - 对
@throws IllegalStateException明确状态前提：「仅在connection.isOpen() == false时触发，反映资源生命周期管理失误」 - 避免模糊描述如“发生错误时抛出”，而应写成「此异常表示调用时机错误，属开发阶段应拦截的逻辑缺陷」
方法签名不声明 throws，但 Javadoc 必须显式标注
非受检异常虽不强制出现在 throws 子句中，但 Javadoc 的 @throws 标签不可或缺：
- 它是调用方唯一能提前了解“哪些编程错误需预防”的正式渠道
- IDE 和文档生成工具（如 javadoc 命令）依赖该标签生成 API 参考，缺失即等于隐藏契约
- 团队代码扫描规则可配置检查：所有 public 方法若抛出非空
RuntimeException子类，其 Javadoc 必须含对应@throws条目
禁止在注释中弱化异常严重性
非受检异常代表“本不该发生”，文档语言需保持一致性，避免误导：
- ❌ 错误示例：“可能抛出
NullPointerException，建议调用前判空” → “建议”削弱了契约刚性 - ✅ 正确表述：“若传入
config为null，将立即抛出NullPointerException；请确保构造参数已完成注入” - 所有
@throws描述都应采用肯定语气，指向责任归属（谁该负责校验、谁该修复）
