RAISE_APPLICATION_ERROR用于抛出自定义异常，需指定-20000至-20999间错误号和非空消息（≤2048字节），可穿透至客户端供应用分类处理；而RAISE仅重抛预定义异常，无业务语义。
怎么用 RAISE_APPLICATION_ERROR 抛出自定义异常
直接抛：在 pl/sql 块里写 raise_application_error，传两个参数——错误编号（-20000 到 -20999 之间）和错误消息字符串。它会立刻终止当前执行，把控制权交还给调用方，并带上你指定的错误号和文本。
常见错误现象是传了超出范围的错误号（比如 -1000 或 -30000），Oracle 会报 PLS-00302: component 'RAISE_APPLICATION_ERROR' must be declared——不是函数没声明，而是编号非法导致编译失败。
- 错误号必须是
-20000到-20999之间的整数，其他值会被拒绝 - 消息长度不能超过 2048 字节，超长部分会被截断，不报错但信息丢失
- 第二个参数不能为空字符串，否则 Oracle 会报
ORA-20000:（只剩个空冒号） - 可以在存储过程、函数、触发器、匿名块里用，但不能在 SQL 表达式中直接调用
RAISE_APPLICATION_ERROR 和 RAISE 的区别在哪
RAISE_APPLICATION_ERROR 是向客户端暴露自定义错误的唯一可靠方式；RAISE 只能重抛已捕获的异常（比如 NO_DATA_FOUND），或抛预定义异常，没法带业务语义。
使用场景很明确：你要让 Java 应用、Python 脚本或前端看到“用户名已存在”这种提示，而不是笼统的 ORA-06512 堆栈——那就必须用 RAISE_APPLICATION_ERROR。
-
RAISE抛出的异常没有错误号（或只有系统号），客户端难做分类处理 -
RAISE_APPLICATION_ERROR的错误号可被应用层catch后 switch 分支，比如捕获-20001就弹登录框，-20002就提示余额不足 - 两者都能触发异常处理块（
EXCEPTION），但只有RAISE_APPLICATION_ERROR能穿透到调用它的 SQL*Plus、JDBC 或 OCI 层
为什么错误号要固定，不能动态生成
因为客户端靠错误号识别业务含义，不是靠错误消息文本。消息可能被翻译、被截断、被日志系统改写，但 -20001 永远代表“主键冲突”。动态拼错误号（比如 -20000 + v_code）会导致维护困难、排查混乱。
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
性能上没差异，但兼容性风险高：Oracle 不保证未来版本支持任意计算表达式作为错误号参数，目前只接受字面量或变量，而变量值若不在合法区间，运行时报错而非编译时报错，更难发现。
- 建议建个包常量表，比如
pkg_err.C_USER_EXISTS CONSTANT PLS_INTEGER := -20001; - 别用
EXECUTE IMMEDIATE拼错误号，语法上虽可行，但失去静态检查，上线后才发现编号越界 - 如果真需要多状态，用不同固定号，而不是一个号配多个消息
在触发器里用 RAISE_APPLICATION_ERROR 的注意事项
触发器里抛这个函数，会回滚当前 DML 语句（比如 INSERT 失败），但不会自动回滚整个事务——这点很多人误以为“触发器报错=事务完蛋”，其实不然。
典型陷阱是：你在 BEFORE INSERT 触发器里校验邮箱格式，用 RAISE_APPLICATION_ERROR(-20005, 'Invalid email')，结果 INSERT 被拦住，但之前同一事务里的 UPDATE 还在内存里，没提交也没回滚。
- 如果希望整个事务失败，得在触发器外层显式
ROLLBACK，或者让应用层捕获后决定 - 触发器中不要调用含 DML 的函数再抛错，容易引发
ORA-04091: table is mutating - 消息里避免拼接敏感字段值（如密码、身份证号），防止泄露到应用日志
