既然JVM提供了RuntimeException，为什么还要自定义Exception？

一、问题来源

先看下面的自定义Exception代码：

package xxx;

public class BusinessException extends RuntimeException {
    private static final long serialVersionUID = -xxxxL;

    public BusinessException(String message, Throwable cause) {
        super(message, cause);
    }

    public BusinessException(String message) {
        super(message);
    }

    public BusinessException(String message, Object... params) {
        super(String.format(message, params));
    }

    public BusinessException(Throwable cause) {
        super(cause);
    }
}

再对比原本JVM提供的RuntimeException代码：

package java.lang;

/**
 * {@code RuntimeException} is the superclass of those
 * exceptions that can be thrown during the normal operation of the
 * Java Virtual Machine.
 *
 * <p>{@code RuntimeException} and its subclasses are <em>unchecked
 * exceptions</em>.  Unchecked exceptions do <em>not</em> need to be
 * declared in a method or constructor's {@code throws} clause if they
 * can be thrown by the execution of the method or constructor and
 * propagate outside the method or constructor boundary.
 *
 * @author  Frank Yellin
 * @jls 11.2 Compile-Time Checking of Exceptions
 * @since   JDK1.0
 */
public class RuntimeException extends Exception {
    static final long serialVersionUID = -xxxxL;

    /** Constructs a new runtime exception with {@code null} as its
     * detail message.  The cause is not initialized, and may subsequently be
     * initialized by a call to {@link #initCause}.
     */
    public RuntimeException() {
        super();
    }

    /** Constructs a new runtime exception with the specified detail message.
     * The cause is not initialized, and may subsequently be initialized by a
     * call to {@link #initCause}.
     *
     * @param   message   the detail message. The detail message is saved for
     *          later retrieval by the {@link #getMessage()} method.
     */
    public RuntimeException(String message) {
        super(message);
    }

    /**
     * Constructs a new runtime exception with the specified detail message and
     * cause.  <p>Note that the detail message associated with
     * {@code cause} is <i>not</i> automatically incorporated in
     * this runtime exception's detail message.
     *
     * @param  message the detail message (which is saved for later retrieval
     *         by the {@link #getMessage()} method).
     * @param  cause the cause (which is saved for later retrieval by the
     *         {@link #getCause()} method).  (A <tt>null</tt> value is
     *         permitted, and indicates that the cause is nonexistent or
     *         unknown.)
     * @since  1.4
     */
    public RuntimeException(String message, Throwable cause) {
        super(message, cause);
    }

    /** Constructs a new runtime exception with the specified cause and a
     * detail message of <tt>(cause==null ? null : cause.toString())</tt>
     * (which typically contains the class and detail message of
     * <tt>cause</tt>).  This constructor is useful for runtime exceptions
     * that are little more than wrappers for other throwables.
     *
     * @param  cause the cause (which is saved for later retrieval by the
     *         {@link #getCause()} method).  (A <tt>null</tt> value is
     *         permitted, and indicates that the cause is nonexistent or
     *         unknown.)
     * @since  1.4
     */
    public RuntimeException(Throwable cause) {
        super(cause);
    }

    /**
     * Constructs a new runtime exception with the specified detail
     * message, cause, suppression enabled or disabled, and writable
     * stack trace enabled or disabled.
     *
     * @param  message the detail message.
     * @param cause the cause.  (A {@code null} value is permitted,
     * and indicates that the cause is nonexistent or unknown.)
     * @param enableSuppression whether or not suppression is enabled
     *                          or disabled
     * @param writableStackTrace whether or not the stack trace should
     *                           be writable
     *
     * @since 1.7
     */
    protected RuntimeException(String message, Throwable cause,
                               boolean enableSuppression,
                               boolean writableStackTrace) {
        super(message, cause, enableSuppression, writableStackTrace);
    }
}

但是我们这时有了疑问，明明JVM提供了RuntimeException，为什么还要自定义Exception？

二、解答

咱们就来深入、系统地解释一下RuntimeException和BusinessException的区别、联系、应用场景

和为什么要自定义BusinessException。

✅ 一句话总结先给你：

BusinessException和RuntimeException本质是一样的异常机制，

但BusinessException是业务语义的封装，可以让代码更清晰、规范、易维护。

一、先看它们之间的继承关系：

Throwable
 └── Exception
      └── RuntimeException
           └── BusinessException   ← 你自定义的异常类

所以结论是：

• ✅ BusinessException是RuntimeException的子类
• ✅ 所有可以使用RuntimeException的地方，都可以使用BusinessException
• ❌ 但直接使用RuntimeException没有语义区分，粒度太粗

二、举例说明：用法的语义差异

1️⃣ 如果你只用系统的RuntimeException：

if (cust == null) {
    throw new RuntimeException("WEITUO人不存在");
}

这代码虽然能跑，但：

• 错误类型无法区分是"系统错误"还是"业务错误"
• 日志里全是RuntimeException，不知道哪个是权限问题，哪个是订单校验失败
• 无法根据类型统一处理

2️⃣ 如果你使用自定义的BusinessException：

if (cust == null) {
    throw new BusinessException("WEITUO人不存在");
}

这样有什么好处？

• ✅ 清晰表达"业务校验失败"
• ✅ 可以专门catch BusinessException做业务友好提示，不用兜底catch所有RuntimeException
• ✅ 后续可以统一加上错误码、分级处理
• ✅ 前后端约定：BusinessException是可以弹出提示给用户的

三、那BusinessException究竟"多了"什么？

从功能角度看，其实没多啥新功能，就是继承自RuntimeException，只是：

✅ 提供语义化的名字(Business)

这是最关键的：命名就是约定

看到 BusinessException，你一眼就知道：

“哦，这是业务上出错了，比如数据不对、权限不足、状态非法等。”

四、实际开发中的应用场景区分

五、统一异常处理器中区别对待

在Spring Boot项目中，我们通常有一个全局异常处理器：

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(BusinessException.class)
    public Result handleBiz(BusinessException e) {
        return Result.fail(e.getMessage()); // 用户能看到的错误
    }

    @ExceptionHandler(Exception.class)
    public Result handleUnknown(Exception e) {
        log.error("系统未知异常", e);
        return Result.fail("系统异常，请联系管理员");
    }
}

这种写法可以让系统把用户错误(业务问题)和程序错误(系统崩了)明确分开对待：

• BusinessException：可以告诉用户
• 其他异常：隐藏细节，避免信息泄露

六、所以总结到底为什么要用BusinessException

✅ 总结

三、所以自定义Exception和RuntimeException只是名称不同，以便于异常分类便于维护，功能上没区别？

✅ 先回答第一个问题：

BusinessException和RuntimeException是一样的吗？

✅ 正确！

从功能上、本质上、底层机制上，它们是一模一样的：

✅ 那为什么还要用BusinessException呢？

正如你说的：

无非就是换个名字，方便维护，方便把 Exception 分组好定位错误。

完全正确！

它是一种"语义化封装"，让你的代码更清晰、有层次，便于统一管理和处理异常(特别是和前端接口配合的时候)。比如：

• 业务异常 → 返回用户看得懂的提示
• 系统异常 → 只记录日志，不暴露给用户

四、各类Exception源码中都有的serialVersionUID是什么？

这其实是Java的一个序列化机制相关的字段。

💡 什么是序列化？

Java中，如果你要把一个对象保存到磁盘、或通过网络传输，就要把它“序列化”为二进制，发出去，之后再“反序列化”回来。

比如你可以这样：

ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("data.obj"));
oos.writeObject(myObject); // 保存对象到文件

☆☆☆但问题是：如果类的定义变了(比如你加了个字段)，以前存的旧数据还能反序列化回来吗？☆☆☆

☆☆☆📌 serialVersionUID就是用来解决这个问题的！☆☆☆

☆☆☆它是每个序列化类的"版本号"，表示这个类的结构签名。☆☆☆

如果你显式写了这个字段，比如：

private static final long serialVersionUID = 123456789L;

☆☆☆那你无论怎么改代码，只要这个值不变，JVM就认为你还是同一个类结构，就可以正常反序列化。☆☆☆

❗ 如果不写会怎样？

• Java会自动根据你的类的字段、方法等生成一个默认的serialVersionUID。
• 但这个值可能随着你每次编译都变 → 反序列化就失败(会抛InvalidClassException)
• 所以建议所有可序列化的类都显式写上这个字段

为什么Exception类里也写这个？

因为 Java 的异常类通常会被序列化，比如：

• 传给远程服务
• 写进日志系统
• 存入 MQ(消息队列)

所以官方的所有异常类，包括RuntimeException、IOException、自定义的BusinessException等，都建议带上serialVersionUID，以保证兼容性。

✅ 总结一下：

📌 补充小贴士

你其实可以不记住serialVersionUID的具体值，但你要记住：

只要你定义了类并实现了 Serializable(异常类默认就支持)，就最好加上它。