自定义受检异常的核心作用是将可预期、可恢复且调用方必须处理的业务风险显式纳入接口契约；需继承exception并声明throws，仅在业务规则违反、外部确定性失败或参数语义合法但业务不接受时抛出；必须由首个具备业务决策能力的位置处理，而非机械传递。
自定义受检异常的核心作用，是把业务中**可预期、可恢复、调用方必须介入处理**的风险显式暴露出来。它不是用来兜底或掩盖问题的，而是让异常成为接口契约的一部分。
什么时候该抛出受检异常
抛出的前提是：你定义的异常类已正确继承 Exception（非 RuntimeException），且方法签名中明确声明了 throws YourCheckedException。仅定义类或仅 throw 实例，编译器不会强制约束。
- 业务规则被违反，且调用方有明确的补救路径 —— 例如账户余额不足时抛出
InsufficientBalanceException，调用方可以提示用户充值或切换支付方式 - 外部依赖返回确定性失败，且该失败需由上层决策 —— 如调用第三方风控接口返回“拒绝授信”，抛出
CreditRejectedException，由服务编排层决定走人工审核还是降级流程 - 输入参数语义合法但业务不接受，且无法在当前层自行修正 —— 如订单创建时传入“已取消”的优惠券 ID，抛出
InvalidCouponStateException，交由 Controller 返回友好提示
什么时候必须处理（而非简单声明）
处理动作发生在**调用链中第一个有能力做业务决策的位置**，不是越早越好，也不是越晚越稳妥。
- 当你可以给出明确的用户反馈或执行替代逻辑时 —— 比如 Service 层抛出
ProductOutOfStockException，Controller 捕获后返回 “库存不足，请稍后再试” 并记录日志 - 当异常代表一种可重试或可降级的场景时 —— 如远程调用抛出
NetworkTimeoutException，可在调用方加一层重试或 fallback 到缓存数据 - 当多个同类异常需要统一响应格式时 —— 不建议在每个 DAO 或 Service 方法里都 try-catch，而是集中到 Web 层或通过
@ControllerAdvice全局捕获并转为标准错误体
常见误区：声明 ≠ 处理，抛出 ≠ 合理
受检异常的强制力只作用于「调用声明了它的方法」这一动作。如果只是机械地 throws 向上传递，最终堆到 main 或顶层 API 方法，却没做任何业务响应，那这个异常就失去了存在价值。
- 避免在 Service 方法里无差别 throws 所有受检异常，导致 Controller 被迫写一堆空 catch 或重复模板代码
- 不要用受检异常包装本应快速失败的编程错误（如传入 null 参数），这类该用
IllegalArgumentException等运行时异常 - 别为了“强制处理”而造异常 —— 如果调用方确实没有合理应对方式，说明它不该是受检异常，考虑改用运行时异常 + 文档约定
