Java中运行时异常（RuntimeException）是无需显式声明或捕获的非受检异常，表示程序逻辑错误而非外部可恢复问题，常见子类包括NullPointerException、ArrayIndexOutOfBoundsException等，设计上强调通过代码修正预防而非异常处理兜底。
Java中的运行时异常（RuntimeException）是无需显式声明或捕获的异常，它们在编译期不强制检查，但一旦发生，会中断程序执行，除非被主动捕获处理。其核心设计意图是表示程序逻辑错误，而非外部可恢复的异常情况。
运行时异常不强制处理
与受检异常（Checked Exception）不同，编译器不会要求方法调用者必须 try-catch 或 throws RuntimeException 及其子类。比如调用 list.get(10) 抛出 IndexOutOfBoundsException，代码仍能正常编译通过。这降低了API使用门槛，也避免了大量冗余的异常处理代码污染业务逻辑。
- 常见子类：NullPointerException、ArrayIndexOutOfBoundsException、ClassCastException、IllegalArgumentException、IllegalStateException
- 设计原则：这类问题通常源于开发者疏忽（如未判空、越界访问），应通过改进逻辑来预防，而不是靠异常处理来兜底
运行时异常反映程序缺陷，而非环境异常
它们代表的是代码本身存在 bug，比如传入非法参数、状态不一致、类型误用等。这类问题在理想开发流程中应在测试阶段暴露并修复，而不是上线后靠 catch 来“容错”。例如：
-
Integer.parseInt("abc")抛出NumberFormatException—— 输入格式错误，应由输入校验提前拦截，而非依赖异常捕获 -
map.put(null, "value")在不允许 null key 的 map 中抛出NullPointerException—— 属于调用方违反契约，应修正调用逻辑
运行时异常可被选择性捕获，但不宜泛化处理
虽然不强制处理，但你仍然可以 catch 它们。不过需注意：过度或笼统地捕获 RuntimeException（如 catch (RuntimeException e)）往往掩盖真正的问题，不利于调试和维护。
立即学习“Java免费学习笔记（深入）”；
- 推荐做法：只在明确知道如何恢复、且该异常确实可能合理出现时才捕获，例如解析用户输入时对 NumberFormatException 做友好提示
- 避免做法：用空 catch 块吞掉异常，或统一打印日志后继续执行，可能导致状态不一致甚至数据损坏
自定义运行时异常应遵循语义清晰、不可恢复的原则
如果需要扩展，继承 RuntimeException 即可。关键是要体现“这是编程错误，不是系统故障”：
- 命名体现错误本质，如
InvalidOrderStateException比MyRuntimeException更具可读性 - 构造函数建议提供带消息和 cause 的重载，便于定位上下文
- 不要把它当作流程控制手段（比如用抛异常代替 return），这违背设计本意
不复杂但容易忽略：RuntimeException 的存在，本质上是在编译安全与开发效率之间做的权衡——它把“该不该出错”的判断权交还给程序员，而不是交给编译器。
