17370845950

Java自定义异常需继承Exception或RuntimeException以区分检查型与非检查型，提供无参、带消息、带cause三种构造方法，可选添加只读业务字段，命名应为动词+名词+Exception并置于业务包中。

在Java中自定义异常类，核心是继承 Exception 或其子类（如 RuntimeException），并提供符合业务语义的构造方法。关键不在于“能不能写”，而在于“为什么这么写”——是否清晰表达了错误场景、是否便于捕获和处理、是否保留了必要的上下文信息。

明确异常类型：检查型 vs 非检查型

选择继承 Exception 还是 RuntimeException，决定了调用方是否必须显式处理该异常：

• 继承 Exception：属于检查型异常（checked exception），编译器强制要求 try-catch 或 throws，适合可预期、应主动恢复的业务问题，比如“用户余额不足”“文件配置缺失”
• 继承 RuntimeException：属于非检查型异常（unchecked exception），调用方可选择忽略，适合程序逻辑错误或不可恢复的意外，比如“参数非法”“状态不一致”

提供实用的构造方法

一个好用的自定义异常，至少应支持以下三种常见构造方式：

• 无参构造：方便快速抛出，如 throw new InsufficientBalanceException();
• 带消息字符串的构造：说明具体原因，如 throw new InsufficientBalanceException("账户余额低于100元");
• 带消息 + 原始异常（cause）的构造：保留底层异常链，便于排查根源，如 throw new DataLoadException("加载用户数据失败", e);

推荐直接复用父类已有构造，并在类中声明即可，无需重复实现逻辑。

补充业务专属字段（按需）

当标准 message 和 cause 不足以支撑诊断或处理逻辑时，可添加业务相关属性：

• 错误码（errorCode）：用于前端展示或日志分类，如 ERROR_BALANCE_INSUFFICIENT
• 影响对象ID（userId、orderId）：便于快速定位问题实体
• 建议操作（suggestion）：提示调用方下一步该怎么做，比如“请先充值再下单”

注意：这些字段应只读（final 或 private + getter），避免破坏异常的不可变性。

命名与包结构要体现领域含义

异常类名应以 Exception 结尾，动词+名词结构更直观，例如：InvalidOrderStatusException、PaymentTimeoutException。避免笼统命名如 MyException 或 BusinessException。

放在与对应业务模块同包下（如 com.example.order.exception），比统一塞进 .exception 顶层包更利于维护和发现。