直接声明throws exception会严重削弱代码可读性和可维护性，属于设计层面的“信号污染”，掩盖真实风险、破坏方法契约、阻碍分层异常处理与监控告警。
直接声明 throws Exception 会严重削弱代码可读性和可维护性，不是语法错误，但属于设计层面的“信号污染”——它掩盖了真实风险，让调用者失去判断依据。
破坏方法契约的明确性
方法签名本应是调用者理解行为的第一入口。声明 Exception 相当于说“我可能出任何问题”，等于没说。调用方无法区分这是网络超时、文件不存在，还是参数校验失败，更没法做针对性处理（比如重试、提示用户、降级）。
- 真实异常类型被隐藏，IDE 和文档工具无法提取有效信息
- 接口变更难以感知：后续加了新异常，也不会触发编译报错或提醒
- 单元测试覆盖困难——不知道该模拟哪类异常场景
迫使调用方采用笼统捕获方式
面对 throws Exception，调用者往往只能写 catch (Exception e)，这带来三个实际问题：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 无法按异常类型分流处理（如 IOException 做重试，SQLException 记录日志）
- 容易误吞本该终止流程的严重异常（比如
OutOfMemoryError继承自Exception，但不应被普通 catch 捕获） - 堆栈追踪丢失上下文：统一 catch 后若只打印日志，原始抛出位置信息可能被覆盖
阻碍分层异常处理策略落地
良好的异常分层依赖清晰的异常类型传递。顶层声明 Exception 会让中间层失去“过滤”和“转换”的依据：
- Service 层本应将底层
IOException转为业务异常FileLoadFailedException，但若 DAO 层只抛Exception，Service 就无法识别原始原因 - Controller 层难以做 HTTP 状态码映射（404 对应
FileNotFoundException，500 对应未预期异常），只能一律返回 500 - 监控告警系统无法按异常分类统计故障率
评估建议：从三处看是否合理
不必禁止所有 Exception，但需确认其出现是否符合以下任一条件：
- 该方法是通用工具类中的泛型操作（如反射调用、JSON 序列化），且已通过文档明确说明每种可能异常及含义
- 异常类型在当前抽象层级确实无法预知（如插件体系中第三方实现抛出的任意异常），此时应配合
getCause()做运行时判断 - 仅用于测试桩或临时占位，且有明确 TODO 注释指向具体异常类型的补充计划
日常开发中，优先声明具体受检异常（IOException、SQLException），对非受检异常保持沉默（如 IllegalArgumentException），比一股脑扔出 Exception 更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
