DBMS_SCHEDULER.DROP_JOB kun hvis den findes

Der er to hovedmønstre, du kan anvende til håndtering af undtagelser; "se før du springer" (LBYL) og "det er nemmere at bede om tilgivelse end tilladelse" (EAFP). LBYL vil anbefale, at man tjekker, om jobbet eksisterer, før man forsøger at droppe det. EAFP ville involvere forsøg på at droppe jobbet og derefter fange og ignorere den specifikke fejl, hvis den opstår.

Hvis du skulle anvende LBYL, kan du forespørge på systemvisningen USER_SCHEDULER_JOBS for at se, om dit job findes. Hvis det gør det, så slip det.

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;

For EAFP er det lidt anderledes; definer din egen undtagelse ved at navngive en internt defineret undtagelse og instansierer den med den fejlkode, du ønsker at fange. Hvis denne fejl så opstår, skal du ikke gøre noget.

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;

Det er værd at bemærke to ting ved denne anden metode.

1. Jeg er kun at fange fejlen, som denne specifikke undtagelse rejste. Det ville være muligt at opnå det samme ved at bruge EXCEPTION WHEN OTHERS men jeg vil varmt anbefale imod gør dette.

   Hvis du håndterer en undtagelse, bør du vide præcis, hvad du vil gøre med den. Det er usandsynligt, at du har evnen til at håndtere hver eneste Oracle-undtagelse korrekt ved hjælp af OTHERS og hvis du gør det, bør du sandsynligvis logge dem et sted, hvor de vil blive bemærket. For at citere fra Oracles retningslinjer for at undgå og håndtere undtagelser :

2. Oracles udbredelse af undtagelser fungerer fra intern blok til ekstern blok, så den oprindelige årsag til fejlen vil være den første undtagelse.