G-5040
🆓Avoid use of WHEN OTHERS clause in an exception section without any other specific handlers.
Reason
There is not 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.
When using a logging framework like Logger, consider making an exception to this rule and allow a when others even without other specific handlers, but only if the when others exception handler calls a logging procedure that saves the error stack (that otherwise is lost) and the last statement of the handler is raise.
Example
Non-Compliant Example
begin
my_package.some_processing();
exception
when others then
my_package.some_further_processing();
end;
/Issues
| Line | Column | Message |
|---|---|---|
| 4 | 9 | Using WHEN OTHERS without any other specific handlers. |
Compliant Solution - ★★★★★
begin
my_package.some_processing();
exception
when dup_val_on_index then
my_package.some_further_processing();
end;
/Explanation
An exception to the rule where when others can be good to log the error and then re-raise it:
begin
my_package.some_processing();
exception
when others then
logger.log_error('Unhandled Exception');
raise;
end;
/References
- same as Trivadis G-5040