execute immediate 执行运行时动态解析的sql字符串，不经过pl/sql编译阶段，故无编译错误，仅抛出ora-/pls-开头的运行时异常，须用exception显式捕获。
EXECUTE IMMEDIATE 执行的是运行时动态解析的 SQL 字符串，它根本不会触发 PL/SQL 编译器的静态语法检查 —— 所以你压根就“捕获不到”编译时错误，因为那类错误压根没发生。
EXECUTE IMMEDIATE 不经过 PL/SQL 编译阶段
PL/SQL 存储过程、函数或匿名块在创建（CREATE OR REPLACE PROCEDURE）时会经历完整编译：词法分析 → 语法校验 → 对象存在性检查 → 类型绑定。而 EXECUTE IMMEDIATE 的字符串内容是在运行时才交给 SQL 引擎去 parse 和 execute 的，PL/SQL 编译器对它只做“字符串字面量”处理，不展开、不验证、不查表是否存在、也不管里面写的是 SELECT 还是 CREATETABLE（少了个空格都行）。
这意味着：
- 你在
EXECUTE IMMEDIATE 'SELCT * FROM emp'里把SELECT拼错了，编译能过，但运行时报ORA-00900: invalid SQL statement -
EXECUTE IMMEDIATE 'CREATE TABLE t (x int)'中表名含非法字符（如小数点、连字符），编译也通过，运行时报ORA-00903: invalid table name - 甚至
EXECUTE IMMEDIATE 'TRUNCATE TABLE non_existent_tab'都能编译成功 —— 错误只在执行那一刻抛出
你真正能 catch 的只有运行时异常
EXECUTE IMMEDIATE 抛出的错误全部属于运行时异常（ORA- 或 PLS- 开头），必须用 EXCEPTION 块显式捕获，且只能捕获它实际执行失败那一刻的错误。
常见误区：
- 以为
WHEN OTHERS能拦住“拼写错误导致无法编译”，其实它拦不住任何编译错误（因为没有编译错误） - 在
EXECUTE IMMEDIATE外层加EXCEPTION却漏掉对SQLCODE的判断，结果ORA-00942: table or view does not exist和ORA-01031: insufficient privileges全被当成同一类错误处理 - 没意识到 DDL 类语句（如
CREATE）成功后会隐式提交，异常回滚不了已执行的 DDL —— 所以不能靠事务回滚来“撤销建表”
如何提前发现 EXECUTE IMMEDIATE 里的潜在错误
没有编译时检查，就得靠人工+工具补位：
- 所有拼接的 SQL 字符串，优先用绑定变量（
USING子句），避免字符串拼接引入语法错或注入风险 - 非拼不可时，用
q'[]语法处理嵌套引号，别硬拼四个单引号 ——q'[INSERT INTO t VALUES ('O''Brien')]比'INSERT INTO t VALUES (''O''''Brien'')'清晰且不易错 - 对关键动态语句，先用
DBMS_OUTPUT.PUT_LINE(v_sql)打印出来，粘到 SQL Developer 里手动执行一遍，确认语法和权限都没问题 - 涉及对象名拼接（如表名、列名），务必过一遍
DBMS_ASSERT.SIMPLE_SQL_NAME或DBMS_ASSERT.SQL_OBJECT_NAME，防止注入或非法标识符
最常被忽略的一点：EXECUTE IMMEDIATE 看似灵活，但它把本该在开发期暴露的问题，全推到了运行期。一旦在生产批处理里执行失败，错误位置可能深藏在多层嵌套的动态 SQL 中，堆栈里只显示“ORA-00900”，没有行号、没有上下文 —— 查错成本远高于写个带语法检查的静态 SQL。
