自定义异常不应继承Error，而应根据可恢复性选择Exception或RuntimeException：外部依赖失败用checked Exception，参数校验等用unchecked RuntimeException，命名需准确反映语义。
自定义异常不用于表示严重错误，Error 及其子类是 JVM 专属的不可恢复问题，业务代码里不该出现自定义 Error。
严重错误（Error）不能也不该由你自定义
OutOfMemoryError、StackOverflowError、NoClassDefFoundError 这些是 JVM 在资源耗尽、栈溢出、类加载失败等底层崩溃时抛出的。它们意味着程序已失去运行基础，连 try-catch 都可能失效。你写一个 DatabaseConnectionError 或 ServiceUnavailableError，名字带 Error，但实际是网络超时或依赖服务暂时不可用——这违背语义，也误导调用方认为“必须放弃整个流程”。这类情况本质可重试、可降级、可提示用户，属于典型业务异常，应继承 Exception。
一般提示类异常要明确归类为 Exception 子类
是否强制处理，取决于它是否属于外部不确定性因素：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 涉及文件、数据库、HTTP 调用等外部依赖失败 → 用 checked exception（如继承 Exception），编译器会提醒调用方必须处理
- 参数校验失败（如 ID 为空）、业务规则冲突（如重复提交）、HTTP 返回 404/401 等 → 用 unchecked exception（如继承 RuntimeException），避免上层堆满 try-catch，同时保持语义清晰（如 UserNotFoundException、InvalidOrderStatusException）
命名和继承要反映真实意图
别只看字面“错”就用 Error；重点看：这个“问题”是不是程序还能继续跑、有没有合理应对策略。
立即学习“Java免费学习笔记（深入）”；
- ✅ 推荐：UserLoginException（继承 RuntimeException）、ConfigLoadException（继承 Exception）
- ❌ 避免：LoginError、ConfigError —— 名字暗示不可恢复，但实际不是
核心就一条：你的异常对象代表什么，得让其他开发者一眼看懂它该不该 catch、要不要重试、值不值得记录后继续执行。
