设计合理的异常层次需要建立以 runtimeexception 为根的自定义业务异常树，并严格区分受检异常与运行时异常。具体做法是定义一个基类 baseexception 继承自 runtimeexception，所有业务异常都继承它，从而避免强制捕获，保持代码整洁。对于可恢复的、由外部系统导致的错误（如网络超时），则使用具体的受检异常或独立的非运行时异常体系。这样设计能让调用者明确知道哪些错误必须处理，哪些属于程序逻辑缺陷。
如何构建统一的业务异常基类
构建统一基类的核心在于继承 RuntimeException 并封装通用的错误码和消息。通过定义 BaseException，我们可以集中管理异常的创建逻辑，确保所有业务异常具有一致的结构。这样做的好处是，在 Controller 层只需捕获一次 BaseException 即可处理所有业务异常，无需针对每种具体异常编写单独的 catch 块。基类通常包含错误码（errorCode）和错误信息（message），并提供便捷的构造函数。
public class BaseException extends RuntimeException {
private final String errorCode;
public BaseException(String errorCode, String message) {
super(message);
this.errorCode = errorCode;
}
public BaseException(String errorCode, String message, Throwable cause) {
super(message, cause);
this.errorCode = errorCode;
}
public String getErrorCode() {
return errorCode;
}
}
上述代码展示了 BaseException 的基本实现。它继承了 RuntimeException，因此是非受检异常。关键属性 errorCode 允许前端或日志系统根据代码快速定位问题类型。构造函数支持传入原始异常 cause，以便保留堆栈跟踪信息，这对于排查底层原因至关重要。在实际使用中，任何业务逻辑抛出的异常都应实例化此类或其子类。
立即学习“Java免费学习笔记（深入）”；
如何划分具体的业务异常类型
划分具体业务异常类型应遵循“语义清晰”和“粒度适中”的原则。不要为每个方法创建一个异常类，而是按业务模块或错误场景分类。例如，用户认证失败可以定义为 AuthenticationException，数据不存在定义为 DataNotFoundException。这些具体异常类只继承 BaseException，不添加额外字段，仅通过类名表达特定的业务含义。这种分层结构使得代码可读性极强，调用者可以通过 catch (DataNotFoundException e) 精确处理特定情况，或者通过 catch (BaseException e) 进行通用兜底处理。
// 具体业务异常示例
public class AuthenticationException extends BaseException {
public AuthenticationException(String message) {
super("AUTH_FAIL", message);
}
}
public class DataNotFoundException extends BaseException {
public DataNotFoundException(String message) {
super("DATA_NOT_FOUND", message);
}
}
以上代码定义了 AuthenticationException 和 DataNotFoundException。它们都调用了父类的构造函数，传入了固定的错误码前缀和具体消息。这种设计保持了异常层次的一致性。当服务抛出 AuthenticationException 时，全局异常处理器可以识别出这是认证相关错误，返回 HTTP 401 状态码；而 DataNotFoundException 则可能返回 HTTP 404。通过这种方式，异常层次不仅组织了代码结构，还直接映射到了系统的错误响应策略。
如何处理嵌套异常中的根因
在处理嵌套异常时，关键在于正确传递和提取根因（Root Cause）。当业务异常是由底层 IO 异常或数据库异常包装而成时，必须通过 cause 参数将原始异常传递给 BaseException。这样，即使上层捕获的是 BaseException，开发者仍然可以通过 e.getCause() 获取到底层的详细错误信息。此外，应避免在业务层吞掉异常，而是将其转换为业务异常后重新抛出，确保错误链不断裂。这种做法有助于在日志中记录完整的异常堆栈，方便运维和开发人员进行故障诊断。
public void updateUser(Long id, UserDTO dto) {
try {
userRepository.update(id, dto);
} catch (SQLException e) {
// 将底层受检异常转换为业务运行时异常
throw new DataAccessException("Failed to update user data", e);
}
}
这段代码演示了如何将 SQLException 包装为 DataAccessException（假设其继承自 BaseException）。注意第二个参数 e 被传入构造函数，这保留了原始异常链。当这个异常被抛出并被全局处理器捕获时，日志中会显示 DataAccessException 及其内部的 SQLException。这种处理方式既满足了业务层对异常类型的控制需求，又保留了底层技术的详细信息，是设计合理异常层次的重要实践。
