Why Not Use WHEN OTHERS - Friday Question

Question

There are several people on this forum that abhor use of WHEN OTHERS in the same vein as GOTO (which really is a bad practice).  I have an open mind and am looking for the reason it should be avoided.
When used to output the state during unexpected exceptions, WHEN OTHES can dramatically reduce debug time.  The only bad exception handler is WHEN OTHERS THEN NULL.  Error logging to a table is important and should include the back trace and call stack in addition to listing pertinent parameter, constant and variable values.  I consider this debug instrumentation.  If you write perfect code or you don't have end users that are very creative in finding bugs that occur because of the convoluted way they get to the code that causes the error you don't need it.  Or you like the thrill of the hunt going slogging through thousands of lines of code to try to figure out what caused the error.  I am lazy and want to have it spelled out for me.  Below is my error logging table (CODE is  a session level transaction identifier used for filtering) and my error logging procedure is equivalent to DBMS_OUTPUT.PUT_LINE.  This makes it easy to take other people's code and replace DBMS_OUTPUT with my error logging.  This becomes very useful for debugging triggers since there is no standard output device.
CREATE TABLE SUPPORT.MESSAGE_LOGS
  CODE        INTEGER                           NOT NULL,
  TEXT        VARCHAR2(4000 BYTE)               NOT NULL,
  CREATED_ON  TIMESTAMP(6)                      NOT NULL,
  CREATED_BY  VARCHAR2(100 BYTE)                NOT NULL,
  OSUSER      VARCHAR2(100 BYTE),
  MACHINE     VARCHAR2(100 BYTE),
  PROGRAM     VARCHAR2(100 BYTE),
  BACK_TRACE  CLOB,
  CALL_STACK  CLOB
Typical insert is:
INSERT INTO message_logs (
              code,
              text,
              created_on,
              created_by,
              osuser,
              machine,
              program,
              back_trace,
              call_stack )
VALUES      (
              utilities.get_xaction_sequence,
              pv_text,
              SYSTIMESTAMP,
              UPPER ( utilities.get_session_user ),
              UPPER ( utilities.get_osuser ),
              UPPER ( utilities.get_machine ),
              UPPER ( utilities.get_program ),
              DBMS_UTILITY.format_error_backtrace,
              DBMS_UTILITY.format_call_stack
Typical error text:
ERROR in UTILITIES.CREATE_FILE: ORA-29280: invalid directory path
Directory = FILEDIR
File Name = _Revoke_From_COGNOS_ALL_Script19-MAR-12.SQL
Linesize = 32000
Text - 1st chacters = -- File created on 19-Mar-2012 11:16:38

Answer 1

Hoek wrote:
C'mon Ed, now shirley you must have an opinion regarding the use of WHEN OTHERS?
Feel free to share it with us
My opinion is that I hate it when an application -- any application, under any framework, in any language -- swallows an error message.  As to getting into the weeds of WHEN OTHERS, I tend to agree that it should be avoided but am open to arguments for exceptions.  Does that sound like waffling?  It's not intended to be.  Here's where I have to make a confession.  When I transitioned from the role of "developer" (we called them "programmer/analyst" then) to dba, my shop was also transitioning from IBM's IMS database (hierarchical) to relational databases - first DB2, then as client-sever architecture came in they settled on Oracle as the C/S database.  Because I was viewed as an "early adopter" and had been doing some development work on our first client-server apps, I was tagged to become our first Oracle DBA. (My first oracle db was v7.3 on Win 3.11)   As a result of that path, I never really got heavily into development with PL/SQL.  I can do OK on  individual procedures - mostly for one-off or stand-alone use. But I never developed that mental framework and toolbox of procedures that only comes with working heavily in a language.  
Don't call me Shirley