自定义异常不应继承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；重点看：这个“问题”是不是程序还能继续跑、有没有合理应对策略。

• ✅ 推荐：UserLoginException（继承 RuntimeException）、ConfigLoadException（继承 Exception）
• ❌ 避免：LoginError、ConfigError —— 名字暗示不可恢复，但实际不是

核心就一条：你的异常对象代表什么，得让其他开发者一眼看懂它该不该 catch、要不要重试、值不值得记录后继续执行。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南