Swallowing exceptions

Have you heard about Oracle can hide some exceptions raised from user code?
One well-known situation is described here.

But there is one more case I've just found.
Try this code:

create or replace procedure test1 is
begin
  raise no_data_found;
end;
/
begin test1; end;
/
begin
      dbms_scheduler.create_job(job_name        => 'T1',
                                job_type        => 'STORED_PROCEDURE',
                                job_action      => 'TEST1',
                                enabled         => TRUE,
                                start_date      => systimestamp,
                                auto_drop       => true);
END;
/
select ACTUAL_START_DATE, LOG_DATE,STATUS,ERRORS from user_scheduler_job_run_details where job_name='T1';

The final query shows STATUS='SUCCEEDED' even though call of test1() raises a no_data_found exception.

Btw, if job is defined slightly differently

  job_type        => 'PLSQL_BLOCK',
  job_action      => 'BEGIN raise no_data_found; end;',

all works as expected, i.e. STATUS='FAILED'.

Checked on 11.2.0.3/4 and 12.1.0.2.

UPD, see MOS doc 1331778.1 for more details.

Do not use instance_id attribute of dbms_scheduler

You must not use dbms_scheduler.set_attribute('YOUR_JOB', 'instance_id', ); for your production system.
If DBA makes some maintenance on your job`s RAC node, the job will just not run during that.
So, if you want your job to run on particular instance(s), you ought to use JOB_CLASS and SERVICES to achieve this.

Another side effect can happen if you run your job through dbms_schdeuler.run_job() with USE_CURRENT_SESSION => FALSE.
Suppose your job attached to node 1 and your session with dbms_schdeuler.run_job happen to connect to node 2. Your job will not run in this circumstance. It will not produce any exceptions or log record with an error.