runtimeexception适用于程序逻辑错误或不可恢复的意外状况，如参数校验失败、状态不一致、编程约定被破坏等；不适合用于可预期的外部失败、业务规则限制或可静默处理的情况。
RuntimeException 适合处理程序逻辑错误或不可恢复的意外状况，而不是业务流程中的正常分支。它不强制调用方捕获，因此应仅用于开发者本应提前避免、运行时难以预测但又无法合理恢复的错误。
适合抛出 RuntimeException 的典型场景
• 参数校验失败：方法内部发现传入参数明显非法（如 null、负数索引、空字符串等），且该错误反映调用方逻辑缺陷。例如 ArrayList.get(-1) 抛出 IndexOutOfBoundsException。
• 状态不一致：对象处于不允许执行某操作的状态，比如调用已关闭的流的 read() 方法，抛出 IllegalStateException。
• 编程约定被破坏：违反方法契约，如重写的 equals() 方法未满足自反性、对称性，可抛 IllegalArgumentException 或 AssertionError（后者多用于断言）。
立即学习“Java免费学习笔记（深入）”；
• 资源不可用且无法重试：如 Class.forName() 找不到类（ClassNotFoundException 是受检异常，但类似逻辑中若类名硬编码且必须存在，可包装为 RuntimeException）。
不适合用 RuntimeException 的情况
• 可预期的外部失败：文件不存在、网络超时、数据库连接中断——这些属于环境问题，应使用受检异常（IOException、SQLException），迫使调用方明确决策（重试、降级、提示用户）。
• 业务规则限制：用户余额不足、订单已取消、权限不够——这是正常业务流的一部分，应定义业务异常（如 InsufficientBalanceException），通常继承 RuntimeException 但需有清晰语义，且应在 service 层统一处理，而非直接 throw new RuntimeException("余额不足")。
• 可以静默处理或默认兜底的情况：比如配置项缺失时采用默认值，无需抛异常干扰主流程。
使用建议与最佳实践
• 优先复用 JDK 已有子类：如 NullPointerException、IllegalArgumentException、IllegalStateException 比自定义异常更易理解，避免滥用 RuntimeException 本身。
• 自定义运行时异常要语义明确：命名体现错误本质（如 InvalidEmailFormatException），并提供带上下文信息的构造方法（含 errorCode、原始异常等）。
• 不要在 finally 块中抛 RuntimeException：可能掩盖 try/catch 中已发生的真正异常，导致调试困难。
• 日志记录要完整：抛出前记录关键参数、状态和堆栈，方便定位是调用方误用还是内部逻辑缺陷。
核心原则是：RuntimeException 表达的是“这里本不该发生”，而不是“这件事可能失败”。用对了，能提升代码健壮性和可维护性；滥用则会让错误边界模糊，增加排查成本。
