我有一个sql脚本,我必须在导入转储后运行.除了其他的脚本,它执行以下操作：
BEGIN --remove program SYS.DBMS_SCHEDULER.DROP_PROGRAM(program_name=>'STATISTICS_COLUMNS_PROG',FORCE=>TRUE); --remove job SYS.DBMS_SCHEDULER.DROP_JOB (job_name => 'STATISTICS_COLUMNS_JOB'); END;
在原始模式中,工作已经被删除了,转储没有作业,脚本失败：
ERROR at line 1: ORA-27475: "DMP_6633.STATISTICS_SET_COLUMNS_JOB" must be a job ORA-06512: at "SYS.DBMS_ISCHED",line 213 ORA-06512: at "SYS.DBMS_SCHEDULER",line 657 ORA-06512: at line 5
如果工作不存在但如果仍然可以删除,我该如何避免这种失败？
有两种主要的模式可以应用于异常处理; (LBYL),“请求宽恕比许可更容易”(EAFP).在尝试放弃之前,LBYL将主张检查该作业是否存在. EAFP将涉及尝试放弃该作业,然后捕获并忽略该特定错误(如果发生).
原文链接：https://www.f2er.com/oracle/204921.html如果您要应用LBYL,您可以查询系统视图USER_SCHEDULER_JOBS查看您的作业是否存在.如果这样做,请放下.
declare
l_job_exists number;
begin
select count(*) into l_job_exists
from user_scheduler_jobs
where job_name = 'STATISTICS_COLUMNS_JOB'
;
if l_job_exists = 1 then
dbms_scheduler.drop_job(job_name => 'STATISTICS_COLUMNS_JOB');
end if;
end;
对于EAFP它略有不同; define your own exception by naming an internally defined exception,并将其与正在寻找的错误代码进行实例化.如果那个错误然后被提出,什么都不做.
declare job_doesnt_exist EXCEPTION; PRAGMA EXCEPTION_INIT( job_doesnt_exist,-27475 ); begin dbms_scheduler.drop_job(job_name => 'STATISTICS_COLUMNS_JOB'); exception when job_doesnt_exist then null; end;
值得注意的是关于第二种方法的两件事情.
>我只是捕捉到这个特定异常提出的错误.使用EXCEPTION WHEN OTHERS可以实现同样的事情,但我强烈建议不要这样做.
如果你处理一个例外,你应该知道你将要做的事情.您不可能使用OTHERS正确处理每一个Oracle异常,并且如果您这样做,您应该将它们记录在他们会被注意的地方.引用Oracle的Guidelines for Avoiding and Handling Exceptions：
Whenever possible,write exception handlers for named exceptions instead of using OTHERS exception handlers.
> Oracle的exception propagation工作从内部块到外部块,所以原来的错误原因将是第一个例外.
