G-5050: Avoid use of the RAISE_APPLICATION_ERROR built-in procedure with a hard-coded 20nnn error number or hard-coded message.

Major

Changeability, Maintainability

Reason

If you are not very organized in the way you allocate, define and use the error numbers between 20999 and 20000 (those reserved by Oracle for its user community), it is very easy to end up with conflicting usages. You should assign these error numbers to named constants and consolidate all definitions within a single package. When you call raise_application_error, you should reference these named elements and error message text stored in a table. Use your own raise procedure in place of explicit calls to raise_application_error. If you are raising a "system" exception like no_data_found, you must use RAISE. However, when you want to raise an application-specific error, you use raise_application_error. If you use the latter, you then have to provide an error number and message. This leads to unnecessary and damaging hard-coded values. A more fail-safe approach is to provide a predefined raise procedure that automatically checks the error number and determines the correct way to raise the error.

Example (bad)

1
2
3
4
begin
   raise_application_error(-20501,'invalid employee_id');
end;
/

Example (good)

1
2
3
4
begin
   errors.raise(in_error => errors.k_invalid_employee_id);
end;
/