phsjhxx

48. Never assign predefined exception names to user defined exceptions.
[CodeXpert 3010]
Reason: This is error-prone because your local declaration overrides the global
declaration. While it is technically possible to use the same names, it
causes confusion for others needing to read and maintain this code.
Additionally, you will need to be very careful to use the prefix
"STANDARD" in front of any reference that needs to use Oracle’s default
exception behavior.
49. Avoid use of WHEN OTHERS clause in an exception section without any other
specific handlers. (CodeXpert)
[CodeXpert 3001]
Reason: There isn't necessarily anything wrong with using WHEN OTHERS, but it
can cause you to "lose" error information unless your handler code is
relatively sophisticated. Generally, you should use WHEN OTHERS to grab
any and every error only after you have thought about your executable
section and decided that you are not able to trap any specific exceptions. If
you know, on the other hand, that a certain exception might be raised,
include a handler for that error. By declaring two different exception
handlers, the code more clearly states what we expect to have happen and
how we want to handle the errors. That makes it easier to maintain and
enhance. We also avoid hard-coding error numbers in checks against
SQLCODE
Example:
--Bad
EXCEPTION
WHEN OTHERS
THEN
IF SQLCODE = -1
THEN
update_instead (...);
ELSE
err.log;
RAISE;
END IF;
--Good
EXCEPTION
WHEN DUP_VAL_ON_INDEX
THEN
update_instead (...);
WHEN OTHERS
THEN
err.log;
RAISE;
PL/SQL Coding Guidelines 35