java自定义父类、子类实现继承案例

<think>好的，用户现在的问题是确认Java自定义异常通常继承Exception和RuntimeException，而不是像NullPointerException这样的异常或Error类。首先，我需要回顾之前的对话，用户之前询问是否可以继承NullPointerException，我解释了为什么不推荐。现在用户似乎理解了这一点，转向更一般的情况，即自定义异常通常继承哪些类。 用户可能是在学习Java异常处理机制，尤其是如何正确创建自定义异常。他们可能对异常的分类（检查型和非检查型）还有疑惑，或者想确认最佳实践。需要明确回答他们的疑问，并巩固他们的理解。 我需要明确区分Exception和RuntimeException的不同。Exception是检查型异常，必须处理或声明，而RuntimeException是非检查型，通常表示编程错误。自定义业务异常通常继承这些基类，而不是特定的运行时异常如NullPointerException，因为后者有特定的语义，继承它们会导致混淆。 同时，用户提到Error类，需要指出Error是用于严重系统问题，应用程序通常不应处理或继承它们。自定义异常不应继承Error，因为那是JVM内部错误，如OutOfMemoryError。 还要举一些例子，说明何时继承Exception（需要调用者处理的情况）和RuntimeException（无需强制处理的业务异常）。强调选择基类的重要性，以及根据业务需求来决定使用检查型还是非检查型异常。 需要确保回答结构清晰，分点说明，可能使用对比的方式，让用户更容易理解不同基类的适用场景。此外，可能需要提醒用户避免常见的错误做法，比如继承不合适的异常类，或者混淆异常类型。 最后，总结关键点，巩固用户的理解，确保他们知道如何正确创建自定义异常，并理解背后的设计原则。</think>**是的，Java自定义异常的正确继承体系应遵循以下规范：** --- ### 一、继承体系选择标准 | 父类 | 类型 | 使用场景 | 处理要求 | |---------------------|------------|----------------------------------|-------------| | $Exception$ | 检查型异常 | 可恢复的业务异常 | 必须try-catch或声明throws | | $RuntimeException$ | 非检查型异常 | 程序逻辑错误/不可预知错误 | 非强制处理 | | $Error$ | 系统级错误 | JVM严重问题（不应继承） | 禁止处理 | --- ### 二、继承$Exception$的场景 **适用情况**：需要调用方**强制处理**的业务异常（符合检查型异常设计哲学） **案例模板**： ```java // 支付失败必须处理 class PaymentFailedException extends Exception { private String transactionId; public PaymentFailedException(String txId, String message) { super(message); this.transactionId = txId; } public String getTransactionId() { return this.transactionId; } } // 调用方必须处理 try { processPayment(); } catch (PaymentFailedException e) { log.error("交易{}失败: {}", e.getTransactionId(), e.getMessage()); retryPayment(); } ``` --- ### 三、继承$RuntimeException$的场景 **适用情况**：参数校验失败等**程序逻辑错误**（符合非检查型异常设计哲学） **案例模板**： ```java // 参数非法直接暴露代码缺陷 class InvalidConfigException extends RuntimeException { private String configKey; public InvalidConfigException(String key) { super("配置项错误: " + key); this.configKey = key; } } // 使用示例（无需强制处理） void loadConfig() { if (!config.isValid()) { throw new InvalidConfigException("database.url"); } } ``` --- ### 四、避免继承的异常类型 #### 1. **$NullPointerException$等JDK运行时异常** - **问题**：破坏标准异常语义 - **错误示例**： ```java // ❌ 违反语义约定 class EmptyCartException extends NullPointerException { public EmptyCartException() { super("购物车为空"); } } ``` #### 2. **$Error$及其子类** - **问题**：用于表示JVM级错误（如$OutOfMemoryError$） - **规范**：应用层代码永远不应继承$Error$ --- ### 五、设计原则对比 | 特征 | 检查型异常($Exception$) | 非检查型异常($RuntimeException$) | |---------------------|----------------------------|---------------------------------| | **错误性质** | 可预见的业务异常 | 代码缺陷或不可控错误 | | **处理要求** | 强制处理 | 非强制处理 | | **典型场景** | 网络超时/支付失败 | 参数校验失败/空指针访问 | | **继承建议** | 需要明确处理流程时使用 | 表示程序逻辑错误时使用 | --- ### 六、最佳实践示例 #### 1. 分层异常设计 ```java // 基础业务异常（非检查型） abstract class BusinessException extends RuntimeException { private ErrorCode code; protected BusinessException(ErrorCode code, String message) { super(message); this.code = code; } } // 具体业务异常 class InventoryShortageException extends BusinessException { public InventoryShortageException(String sku) { super(ErrorCode.INVENTORY_SHORTAGE, "商品库存不足: " + sku); } } ``` #### 2. 参数校验框架集成 ```java // 与Spring Validation结合 class ApiRequestValidationException extends RuntimeException { private List<FieldError> fieldErrors; public ApiRequestValidationException(List<FieldError> errors) { super("请求参数校验失败"); this.fieldErrors = Collections.unmodifiableList(errors); } } ``` --- ### 七、扩展建议 1. **全局异常处理**：结合Spring的@ControllerAdvice统一处理自定义异常 2. **错误码规范**：为自定义异常附加错误码体系 ```java enum ErrorCode { INVALID_PARAM(40001), SERVICE_UNAVAILABLE(50001); private final int code; ErrorCode(int code) { this.code = code; } } ``` 3. **文档生成**：通过Swagger等工具暴露异常类型给API调用方 **总结**：自定义异常应通过继承$Exception$或$RuntimeException$建立清晰的错误语义层级，避免污染JDK标准异常语义，这是构建可维护异常体系的核心原则。