CHECK约束不抛出可捕获的PL/SQL异常，仅触发ORA-02290中止语句；需用触发器或存储过程实现复杂校验与自定义处理。
oracle 的 check 约束本身不抛出可捕获的 pl/sql 异常，它只在违反时直接报 ora-02290 并中止语句执行；想在插入/更新前做复杂校验并自定义处理逻辑，不能只靠 check，得用触发器或存储过程封装。
ORA-02290 是什么，为什么它不能被常规 EXCEPTION 捕获
ORA-02290: check constraint (%s.%s) violated 是约束级错误，在 SQL 语句执行阶段由 Oracle 内核强制拦截，不经过 PL/SQL 引擎的异常处理路径。即使你在 BEGIN...EXCEPTION 块里执行 INSERT，只要触发了 CHECK 违反，整个语句就已失败，EXCEPTION 部分不会运行——除非你显式用 SAVEPOINT + WHEN OTHERS 捕获再判断错误号。
- 它不是 PL/SQL 预定义异常（如
NO_DATA_FOUND），没有对应异常名，必须靠SQLCODE判断 - 若在匿名块中执行 DML 后没加异常处理，会直接报错退出，调用方收不到可控反馈
- 即便加了
WHEN OTHERS，也需手动检查SQLCODE = -2290才能区分是 CHECK 违反还是其他问题
想让校验可干预，该用触发器而不是 CHECK
当需要在插入前做正则校验、查关联表、调用函数或记录日志时，BEFORE INSERT OR UPDATE 触发器比 CHECK 更灵活。它运行在 PL/SQL 上下文中，可自由使用 REGEXP_LIKE、SELECT ... INTO、RAISE_APPLICATION_ERROR 等。
- 触发器里可以用
RAISE_APPLICATION_ERROR(-20001, '邮箱格式错误')抛出自定义错误，调用方能明确识别 - 支持跨列逻辑，比如
IF :NEW.start_date > :NEW.end_date THEN ... END IF; - 避免老版本 Oracle 对
REGEXP_LIKE在 CHECK 中的限制（12.1 及之前不支持） - 注意：触发器性能开销略高，高频写入表要测压；且需确保触发器逻辑幂等，避免递归触发
如果坚持用 CHECK，怎么让错误更友好
纯 CHECK 约束无法改变报错信息内容，但可以通过命名和注释降低维护成本：
- 约束名带业务含义，例如
chk_emp_email_format而非sys_c0012345 - 用
COMMENT ON CONSTRAINT补充说明，如COMMENT ON CONSTRAINT chk_emp_email_format IS '要求含@和域名，不校验MX记录'; - 建表时加
DISABLE NOVALIDATE先挂载约束，后续用ALTER TABLE ... ENABLE VALIDATE分批校验存量数据，避免建表失败 - 对已有数据的表加新 CHECK，务必先确认数据合规，否则会报
ORA-02293（无法验证约束）
真正需要“校验+处理”的场景，绕不开存储过程封装
前端或应用层调用一个统一入口，把校验、插入、错误分类全包在里面，比分散在各处的 CHECK 或触发器更可控：
- 过程内先用
IF NOT REGEXP_LIKE(:p_email, '^[^@]+@[^@]+\.[^@]+$') THEN RAISE_APPLICATION_ERROR(-20002, '邮箱格式非法'); - 再
INSERT，并在EXCEPTION块中捕获ORA-02290做降级处理（如写审计表、返回特定码） - 所有业务规则集中一处，改格式只需动过程，不用改 N 张表的约束
- 注意：过程里不要用
AUTONOMOUS_TRANSACTION记日志，否则约束失败时日志仍会提交，造成数据不一致
CHECK 约束适合静态、轻量、确定性的断言；一旦涉及正则、函数、跨表、空值安全或需要差异化提示，就得交由 PL/SQL 主动控制——它的校验点不在 DDL 层，而在你写的每一行 IF 和 RAISE 里。
