Java方法设计中应区分可恢复业务异常与不可控系统异常，用自定义checked异常（如InsufficientBalanceException）显式throws关键业务错误，runtime异常仅用于无法恢复的非法状态，避免滥用异常控制流程。
在 Java 方法设计中，用异常声明来抛出业务错误，核心是区分“可恢复的业务异常”和“不可控的系统异常”，并合理选择 checked 或 unchecked 异常类型，让调用方明确感知、主动处理业务规则失败。
明确业务异常语义，自定义受检异常类
业务错误（如“余额不足”“用户不存在”“订单已取消”）不是程序 bug，而是正常流程中的预期分支。为体现其重要性，建议定义继承 Exception 的自定义异常类，并在方法签名中显式 throws：
- 命名清晰，如
InsufficientBalanceException、UserNotFoundException - 构造函数支持传入业务码（如
ERR_BALANCE_INSUFFICIENT）和提示信息，便于统一错误响应 - 方法声明时写出异常，强制调用方考虑“这笔钱能不能扣”“这个人找不找得到”
非关键或无法恢复的业务问题，用运行时异常
有些业务判断失败虽属业务范畴，但调用方通常无法重试或补偿（如参数校验失败、状态非法转换），此时用 RuntimeException 子类更自然：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如
IllegalStateException表达“当前订单状态不允许退款”，IllegalArgumentException表达“传入的手机号格式错误” - 不强制
throws声明，减少模板代码；但应在 Javadoc 中明确说明触发条件 - 避免滥用
RuntimeException掩盖真正需要处理的业务分支
方法签名中只声明真正需要调用方决策的异常
不是所有异常都要写在 throws 里。原则是：只有调用方能根据该异常做出有意义决策时才暴露。
立即学习“Java免费学习笔记（深入）”；
- 比如支付方法抛出
InsufficientBalanceException，上层可引导用户充值；但若内部 HTTP 调用失败，应封装为更抽象的PaymentServiceUnavailableException，而非直接抛IOException - 底层技术异常（如数据库连接中断）一般不应泄露给业务层，而应转为业务语义明确的异常
- 一个方法最多声明 2–3 种核心业务异常，避免
throws AException, BException, CException, DException这种难以维护的签名
配合返回值与异常，保持契约清晰
异常不是替代返回值的工具。不要为了“省一个 if”就用异常控制流程（如用 NoSuchElementException 替代 Optional.isEmpty()）。
- 查询类操作优先返回
Optional<T>或null（配以文档说明），而非靠异常表示“没找到” - 变更类操作（创建、更新、支付）才更适合用异常表达“为什么变不了”
- 统一异常处理机制（如 Spring 的
@ControllerAdvice）可集中转换业务异常为 HTTP 状态码和 JSON 错误体，但方法本身仍需真实抛出原始业务异常
