Java 17密封类不能用于异常体系，因编译器禁止sealed修饰Throwable及其子类，且与异常动态抛出、跨模块传播及JVM字节码机制根本冲突。
Java 17 的密封类（Sealed Classes）本身不适用于直接限制异常类的继承体系，这是由 Java 异常机制的设计原则和语言规范共同决定的。它不能、也不应被用于改造 Throwable 及其子类（如 Exception、RuntimeException）的继承结构。
为什么不能用 sealed 修饰异常类？
Java 规范明确禁止对 Throwable 及其标准子类使用 sealed：
-
编译器强制拦截：若尝试写
public sealed class MyException extends Exception permits ...，Javac 会直接报错：error: sealed classes cannot extend Throwable or its subclasses； - 运行时语义冲突：异常对象需在任意栈帧中动态构造并抛出，而密封类要求所有子类在编译期静态可知且同模块可见——这与异常的动态传播、跨模块/跨类加载场景（如框架统一异常处理）根本矛盾；
-
JVM 层面限制：
Throwable是 JVM 特殊类，其子类实例化、序列化、栈追踪等行为深度绑定字节码指令（如athrow），密封类的ACC_SEALED标志与之不兼容。
那如何安全地约束自定义异常的使用范围？
虽然不能密封异常类本身，但可通过以下替代设计模式实现同等目标：显式控制“哪些异常能被业务逻辑抛出或捕获”，从而达成类型安全与可维护性：
-
用密封接口 + 静态工厂封装异常构造：定义一个密封接口（如
BusinessError），让所有受控异常实现它，并将具体异常类设为private static final内部类。对外仅暴露BusinessError类型和工厂方法； -
配合枚举建模错误码与语义：对状态明确、无数据携带需求的场景，优先用
enum（如ErrorCode）表示错误种类，再通过统一异常包装器（如AppException.of(ErrorCode.TIMEOUT)）生成实例； -
在 API 边界做类型过滤：例如 REST 控制器中，只声明
throws BusinessError（接口），并在全局异常处理器中校验实际抛出的异常是否属于预定义集合（反射检查类名白名单或标记接口），非法异常一律转为 500 并告警。
常见误用与风险提示
以下做法看似“模拟密封”，实则破坏异常契约，务必避免：
立即学习“Java免费学习笔记（深入）”；
- 试图用
non-sealed开放某个异常子类 → 仍无法绕过Throwable禁令，编译失败； - 在模块 info.java 中导出异常类但隐藏其实现 → Java 模块系统不阻止反射构造，也无法防止
catch (Exception e)捕获，失去类型约束意义； - 依赖 IDE 或 Lint 工具做“软限制” → 缺乏编译期保障，上线后易被绕过，不符合高可靠性系统要求。
真正需要强类型约束的错误建模，应转向密封接口或代数数据类型（如 Kotlin 的 sealed class + Result），而非强行改造 Java 异常体系。异常的本质是“逃逸路径”，而密封类的本质是“穷尽集合”——二者设计意图不同，混用只会增加复杂度和隐患。
