异常声明是契约而非补丁，须精准声明调用者需关心的受检异常，避免泛化；按语义区分异常类型，正交失败维度并列声明；运行时异常不写throws但须在javadoc中明确标注。
方法签名里的异常声明，不是补丁，而是契约的显性表达。它告诉调用者“这个方法在什么条件下会失败”，而不是“我内部可能抛出什么”。清晰的关键，在于精准、收敛、可推断。
只声明调用者需要关心的受检异常
受检异常（如 IOException、SQLException）必须出现在 throws 列表中，这是编译器强制的契约信号。但不要把所有底层异常都往上堆砌。
- 如果父类方法声明 throws IOException，子类重写时不能新增 throws HttpException——这破坏契约；应包装为 IOException 子类，或统一转为语义等价的运行时异常（如 DataAccessException），并保留原始异常作为 cause
- 避免声明 throws Exception 或 throws Throwable：它们无法传达任何具体风险，等于没说
- 对明确属于编程错误的异常（如 NullPointerException、IllegalArgumentException），不列入 throws ——它们应通过前置校验暴露，而非靠 throws 提醒
用异常类型本身传递语义，而非仅靠消息字符串
异常类名是第一层语义载体。不同故障场景应映射到不同异常类型，让调用者能按类型做差异化处理。
- 输入参数非法 → IllegalArgumentException（带字段名，如 “userId cannot be null”）
- 外部资源不可用（网络超时、连接拒绝）→ IOException 或其定制子类（如 RemoteServiceUnavailableException）
- 业务规则被违反（余额不足、状态不允许操作）→ 自定义受检异常（如 InsufficientBalanceException）或运行时异常（若属领域核心规则）
- 配置缺失或格式错误 → ConfigurationException，而非泛化为 RuntimeException
多异常声明要体现正交失败维度
当一个方法可能因多个独立原因失败时，可在 throws 中并列声明，但需确保它们代表真正不同的故障域。
- 正确示例：public void loadUser(long id) throws UserNotFoundException, IOException
→ 找不到用户（业务语义）和读取数据失败（I/O 故障）是两类正交问题，调用者可分别捕获、重试或降级 - 错误示例：throws IOException, SQLException, TimeoutException
→ 若实际只走数据库，TimeoutException 是 SQLException 的一种表现，不应平级并列；应由统一的数据访问异常封装 - 异常之间保持“非包含”关系：避免同时声明 IOException 和它的子类 FileNotFoundException，除非你明确允许调用者针对子类做特化处理
运行时异常不写 throws，但要在 Javadoc 明确标注
RuntimeException 及其子类不强制声明，但不等于可以忽略。它们往往是调用前必须满足的前提条件，应在文档中白纸黑字写清。
- Javadoc 中使用 @throws IllegalArgumentException 等标签，说明触发条件和变量（如 “if
configis null”） - 这类异常通常源于参数校验失败或非法状态，应在方法入口立即抛出，不进入主逻辑——让失败点靠近调用点，缩短排查路径
- 禁止在 catch 块里把受检异常“吞掉”后静默抛出 RuntimeException，这会切断异常传播链，丢失原始上下文
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
