runtimeexception 是鲁棒性设计的反向探测器，暴露逻辑疏漏而非外部故障；应通过防御式编程、收缩信任边界、显式契约和异步隔离等手段，在异常发生前拦截风险，而非依赖 try-catch。
RuntimeException 本身不是增强鲁棒性的工具，而是暴露鲁棒性缺口的信号。它不强制开发者处理，但恰恰因为“可忽略”，反而成为检验系统是否真正健壮的关键标尺。
RuntimeException 是鲁棒性设计的反向探测器
这类异常（如 NullPointerException、ArrayIndexOutOfBoundsException）通常源于逻辑疏漏，而非外部不可控因素。它们在运行时爆发，说明前置防御失效——比如没校验输入、没判空、没做边界检查。一个鲁棒的系统不会等异常发生才响应，而是在异常可能发生的前一刻就拦截或转化风险。
- 空指针不是“意外”，是未对引用做防御性假设的结果
- 数组越界不是“运气差”，是循环控制或长度计算缺乏容错表达
- 类型转换失败不是“数据突变”，是契约未被显式声明或验证
用防御式编程替代被动捕获
对 RuntimeException 做 try-catch 并非鲁棒性提升，而是掩盖问题。真正提升鲁棒性的做法，是让这些异常根本无机会抛出：
- 方法入口做参数校验，用 Objects.requireNonNull() 主动拒绝 null，比事后 catch 更早切断错误传播
- 集合操作优先用 Optional 或 Stream API，避免裸露 get() 或 index 访问
- 对外部输入（如 JSON、配置、用户表单）做 schema 级校验，把 NumberFormatException 挡在解析之前
- 关键业务路径中插入断言（assert），在开发/测试阶段快速暴露逻辑矛盾
异常分类决定鲁棒性策略重心
RuntimeException 属于 unchecked 异常，编译器不强制处理——这正意味着它的根源在代码逻辑内部。因此，提升鲁棒性不能靠“兜底捕获”，而要聚焦三类动作：
- 收缩信任边界：不假设调用方传来的对象一定有效，也不假设下游服务返回的数据结构永远稳定
- 显式暴露契约：用 @NonNull、@NotNull 注解或 Kotlin 的非空类型系统，在编译期或 IDE 层面强化约束
- 构建失败缓冲带：在模块边界（如 API 入口、DAO 层出口）统一做空值/非法值转换，返回有意义的业务错误码或默认值，而非让 RuntimeException 向上穿透
异步场景下 RuntimeException 更需主动隔离
在 CompletableFuture 或协程中，未捕获的 RuntimeException 容易静默丢失，导致任务中断却不通知、资源不释放、状态不回滚。这时鲁棒性体现在结构化设计上：
- 用 exceptionally() 提供降级结果，保证链式调用不中断
- 在 supplyAsync 内部包裹关键逻辑，避免原始 lambda 抛出未处理异常
- 配合 timeout() 和 handle() 统一管理超时、异常、成功三种终态，不让任何分支“掉线”
- 所有异步任务绑定作用域（如 virtual thread scope 或 coroutine scope），确保异常触发时能联动取消与清理
