Java能捕获Oracle触发器中RAISE_APPLICATION_ERROR抛出的异常，因其被JDBC封装为SQLException，且ex.getErrorCode()直接返回ORA编号绝对值（如-20001→20001），应以此精准识别业务错误而非依赖sqlState或解析消息。
Oracle触发器里用 RAISE_APPLICATION_ERROR 抛异常，Java 为啥捕不到？
因为 oracle 触发器中调用 raise_application_error 时，jdbc 默认会把它包装成 sqlexception，但错误码不是标准 sqlstate，而是 oracle 自有的 ora- 编号（比如 ora-20001）。很多开发者只检查 sqlstate 或 errorcode 字段，却忽略了 oracle 驱动把真实错误码藏在了 geterrorcode() 返回值里——而这个值对应的是 oracle 的 ora 编号去掉前缀后的数字部分。
-
RAISE_APPLICATION_ERROR(-20001, '余额不足')→ Java 中ex.getErrorCode()返回20001，不是 -20001，也不是 "20001" -
getSQLState()通常是"72000"（Oracle 通用未分类异常），不能靠它区分业务逻辑错误 - 必须用
getCause()往上找原始异常不靠谱——JDBC 驱动已做了一层封装，SQLException就是根异常
怎么从 SQLException 提取 ORA- 错误码？
别解析异常消息字符串（getMessage()），那不可靠：可能被本地化、含空格或换行。正确方式是直接读驱动填充好的 errorCode 字段，再按需拼回 ORA- 格式。
- 调用
ex.getErrorCode()获取整数，如20001 - 若需日志或判断分支，可转成字符串：
"ORA-" + ex.getErrorCode() - 注意：Oracle 官方文档明确说明，
getErrorCode()对RAISE_APPLICATION_ERROR返回的就是负数参数的绝对值（即传 -20001 → 返回 20001） - 如果返回 0 或负数（比如 -1），说明不是
RAISE_APPLICATION_ERROR抛的，可能是连接中断、超时等底层错误，要另作处理
捕获时要不要用 try-catch 包住整个事务？
要，而且必须在执行引发触发器的 DML 语句之后立即捕获——比如你执行 INSERT，触发器在 AFTER INSERT 里抛错，那么异常就在 executeUpdate() 这一行抛出，不是在 commit() 时。
- 错误写法：先
executeUpdate()，再commit()，只在commit()外 catch —— 此时异常根本不会到那里 - 正确写法：DML 操作和异常捕获紧挨着，例如：
try { stmt.executeUpdate("INSERT INTO account VALUES (1001, 500)"); } catch (SQLException ex) { if (ex.getErrorCode() == 20001) { // 处理余额不足 } } - 如果用了 Spring
JdbcTemplate或 MyBatis，它们默认把SQLException转成 unchecked 异常（如DataAccessException），此时得用getCause()往下挖到原始SQLException，再取errorCode
ORA 错误码重复怎么办？不同触发器都用 -20001？
会冲突。Oracle 不阻止你重复使用同一个错误编号，但 Java 层无法区分来源。实际项目里必须约定编码规则，否则业务逻辑分支容易串。
- 建议按模块分段：账户模块用
-20100～-20199，订单用-20200～-20299 - 触发器里写死编号不灵活，可考虑用常量表或包变量管理，但 JDBC 层仍只能靠
getErrorCode()数值判断 - 如果真遇到编号冲突又没法改触发器，唯一补救是解析
getMessage()中的特定关键词（如 "余额"、"库存"），但这是下策，仅限临时救急
触发器抛错不是黑盒，关键是记住：Oracle 驱动把 RAISE_APPLICATION_ERROR 的编号原样塞进了 SQLException.getErrorCode()，其它字段都是干扰项。别信消息字符串，也别绕远路找 cause。
立即学习“Java免费学习笔记（深入）”；
