受检异常通过编译强制约束调用方处理特定业务失败，需继承exception、命名不含“runtime”、提供标准构造函数，并在方法签名中显式throws；配套ci检查、统一错误提示和openapi映射保障契约落地。
在接口设计中用受检异常约束调用方必须显式处理潜在故障，本质是把“这个操作可能因外部条件失败”这一业务事实，变成编译器能识别、能拦截的契约。不是靠文档提醒，而是让代码通不过编译，除非开发者明确回应了风险。
定义语义清晰的受检异常类
异常类要真正起作用，必须满足三个硬性条件：
- 直接继承 Exception，不能是 RuntimeException 的子类（哪怕只隔一层也不行）
- 类名不含 “Runtime” 字样（如
DeviceBusyException合法，RuntimeDeviceBusyException就会被编译器忽略） - 提供两个构造函数：
public XxxException(String message)和public XxxException(String message, Throwable cause)，确保能传入业务上下文并保留原始异常链
在方法签名中显式声明 throws
只定义异常类不够，必须把它写进 public 接口的方法签名里：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如：
public void writeConfig(Conf conf) throws ConfigPermissionDeniedException, ConfigLockedException - 每个
throws项对应一种独立、正交的失败原因，不合并为一个泛化异常 - 调用该方法时，IDE 或 javac 立刻报错：“unreported exception ConfigLockedException; must be caught or declared to be thrown”
驱动调用方做差异化响应
受检异常不是为了增加 try-catch 行数，而是让每种失败都导向具体动作：
catch (ConfigLockedException e) { showUserToast("配置正被他人编辑，请稍后重试"); }catch (ConfigPermissionDeniedException e) { redirectToPermissionPage(e.getRequiredScope()); }- 若当前层无法处理（如权限缺失），就继续
throws向上传递，直到有责任边界（如 Controller 层）统一兜底
配套机制防止契约被绕过
仅靠编译器还不够，需工程手段加固：
- CI 流水线检查：禁止
catch (Exception e) { e.printStackTrace(); }这类空处理 - 统一基类重写
getMessage()，自动附加建议动作，例如“请调用ConfigService#refreshLockStatus()后重试” - OpenAPI 文档将这些受检异常映射为明确的 HTTP 4xx 状态码，并注明触发条件与前端推荐响应逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
