throws对runtimeexception无效：编译器不强制声明或捕获，写上合法但冗余，旨在提示开发者修复逻辑错误而非掩盖异常。
因为 RuntimeException 是非受检异常（unchecked exception），Java 编译器根本不要求它被声明或捕获——throws 写上去不报错，但也不起强制约束作用。
编译器对非受检异常“睁一只眼”
Java 的异常检查机制只针对受检异常（即继承自 Exception 但不是 RuntimeException 子类的异常）。编译器在编译期会扫描代码，一旦发现受检异常未被捕获也未在方法签名中声明 throws，就直接报错，阻止编译通过。
而 RuntimeException 及其子类（如 NullPointerException、IllegalArgumentException）被明确排除在该检查机制之外。哪怕你在方法里抛出它，也不需要写 throws；就算写了，调用方依然可以完全忽略，不会触发编译错误。
设计意图：把责任交还给开发者
这类异常代表的是程序内部的逻辑缺陷，比如：
- 传了
null却没校验就调用方法 - 数组索引明显越界却没做边界判断
- 构造对象时用了非法状态参数
它们本不该出现在生产环境，修复方式是改代码，而不是靠层层 try-catch 或 throws 来掩盖。编译器不强制，就是在提醒你：“这不是环境问题，是你写错了。”
写了 throws RuntimeException 会发生什么？
语法上合法，但实际无意义：
- 调用方无需处理，也不会编译失败
- IDE 和静态分析工具通常会标为冗余警告
- 反而可能误导读者，让人误以为这是需要关注的外部风险
- 违反 API 清晰性原则——方法签名应只声明真正需要调用方决策的受检异常
对比受检异常：IOException 就不一样
像 IOException 这类异常，源于文件读写、网络请求等外部不可控因素。Java 认为这类问题可预见、可恢复，所以强制要求显式应对：
- 要么在方法内
try-catch处理 - 要么用
throws IOException告知调用方“这事你来管” - 缺一不可，否则编译失败
这种强制力不存在于 RuntimeException 上——它不是被“豁免”，而是从一开始就没被纳入强制检查范围。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
