java中通过自定义受检异常规范驱动模块错误契约，要求调用方必须显式处理可恢复、需业务决策的错误，如devicebusyexception；需继承exception、命名具体、在方法签名中明确throws、实现精准抛出、调用方差异化处理。
在 Java 异常处理中，通过自定义受检异常（checked exception）来规范底层驱动模块的错误契约，核心是让调用方**必须显式处理或声明传播**底层可能出现的、业务上可预期且需干预的错误场景，从而把“哪些错误可能发生、该如何响应”以编译期强制的方式写进接口契约。
定义明确语义的受检异常类
受检异常应代表驱动模块中**可恢复、需业务决策**的失败情况（如设备忙、协议不匹配、资源临时不可用），而非程序 bug 或系统崩溃。命名和构造需体现领域含义：
- 继承 Exception（非 RuntimeException），确保编译器强制处理
- 提供含上下文的构造函数，例如：public DeviceBusyException(String deviceName, long retryAfterMs)
- 避免泛化名称（如 DriverException），优先用 SerialPortTimeoutException、UsbPermissionDeniedException 等具体名称
在驱动接口方法签名中显式声明 throws
将自定义受检异常写入 public API 方法的 throws 子句，形成机器可读的契约文档：
- 例如：public void sendCommand(byte[] cmd) throws SerialPortTimeoutException, InvalidChecksumException
- 每个 throws 项对应一种独立、正交的失败原因，不合并为一个“DriverFailureException”
- 不声明 RuntimeException 子类（如 NullPointerException），它们属于编程错误，不应纳入契约
驱动实现中精准抛出，不包装也不吞没
底层驱动代码在识别到对应错误条件时，直接抛出对应自定义异常，保持原始上下文：
- 捕获底层 IOException 后，判断是否属于“端口忙”，则转为 throw new SerialPortBusyException(portId, 1000)
- 避免用 new RuntimeException(e) 包装后抛出——这绕过了受检机制，破坏契约
- 不在 catch 块里静默吞掉异常或只打日志——调用方失去响应机会
调用方按契约做差异化处理
上层模块依据 throws 声明，针对每种异常编写有意义的恢复逻辑，而非统一 try-catch Exception：
- catch (SerialPortBusyException e) { delayAndRetry(e.getRetryAfterMs()); }
- catch (InvalidChecksumException e) { logCorruptedFrame(e.getFrame()); throw new BusinessException("校验失败，指令丢弃"); }
- 若无法处理某异常（如权限缺失），应在方法签名中继续 throws，向上传递责任
不复杂但容易忽略：受检异常的价值不在“多抛几个”，而在让每一个 throws 都成为接口设计时认真权衡后的明确承诺——什么错会发生、谁该负责、怎么应对。契约成立的前提，是异常类型有边界、语义不模糊、抛出不随意。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
