WHEN OTHERS not catching error

Question

I have the following SQL script:
WHENEVER SQLERROR EXIT FAILURE
SET VERIFY OFF
DECLARE
error_notes VARCHAR2(500);
BEGIN
process_test('TX', '&1');
EXCEPTION
WHEN OTHERS THEN
log_error (
SQLCODE,
SUBSTR(SQLERRM, 1,150),
SUBSTR(SQLERRM,151,150),
error_notes);
COMMIT;
END;
EXIT;
This script is executed from a Unix command line SQLPLUS uid/pwd@SID @scriptname.sql. The catch is that I am trying to test my exception handling. To test the error I have intentionally renamed a table that the PL/SQL procedure 'process_test' is based on, so that it shows up as invalid. The failure is detected by the WHENEVER and the Unix status gets set to 1 so that the Unix end of the error trap operates fine. The problem is that there is nothing inserted into the error_log table. Is it that the WHENEVER clause at the top (there to propogate the error out to Unix) is causing the control to drop out of the block immediately after the error occurs so that my exception handler is not allowed to run? I need it in there to send the fail code out to Unix. The process in question is loading some tables with data from external tables, and after it loads a file it deletes it. I want to stop the deletion from occurring if the load didn't happen. The part is actually working, but it's not logging the error in the error table. Here's the error message, it if helps:
process_test('TX', '/home/datatest/trans005.dat');
ERROR at line 7:
ORA-06550: line 7, column 5:
PLS-00905: object OUTB.PROCESS_TEST is invalid
ORA-06550: line 7, column 5:
PL/SQL: Statement ignored
Shouldn't this get caught by the WHEN OTHERS and dealt with before it exits the block, or is the WHENEVER SQLERROR clause causing control to move out of the block before the exception handler runs?

Answer 1

Oh. Well, this SQL script executed a procedure that was invalid. Yes, it did show as invalid in PL/SQL Dev as soon as I changed the table name. I'm actually a big fan of packages and such. I was trying to think of a way to force an error in what is basically a simple system. There's not a lot of places for it to be broken. I can see now that I need to find a better place to break it. This way isn't allowing the PL/SQL exception handlers to be tested.
The script itself is to be executed by a CRON job in Unix to fire off the file extracts. It's driven from Unix because we need to loop through a bunch of Unix file names. It creates a symbolic link so we can use External Tables to do the data extracts from the flat files, then it deletes the source file and moves on to the next one. The error trap is to stop the deletion of the source file if anything went wrong, so the file is still there for the next pass to load it. (Theoretically, once any errors have been corrected...)