How to store EXCEPTION code in separate code block for ease of maintenance?

Question

I'm new to pl/sql and oracle, but I've created a lot of procedures that use the same business logic for security checks. I've tried to outline an example stored procedure below.
If my security checks that I use to raise exceptions are always the same for all of the stored procedures, what's the best way to structure the procedure/environment so that if I ever want to change (such as add or delete) the exceptions, that I don't need to manually edit each individual procedure? Could I call another procedure to do this, and the exceptions will be raised up through it to the calling procedure? Any example would be much appreciated.
create or replace
PROCEDURE MY_SPROC(
AS
begin
/***** security check ****/
SELECT col1, col2 INTO v_col1, v_col2
FROM my_table1 WHERE user_email = in_user_id;
-- check 1
IF v_col1 != in_var1 THEN
RAISE e_bad_input;
-- check 2
ELSIF v_col2 = in_var2 THEN
RAISE e_bad_form;
ELSIF ...
END IF;
... /* body of code */
EXCEPTION
WHEN e_bad_input THEN out_msg := 'Error 1 …';
WHEN e_bad_form THEN out_msg := 'Error 2 ...';
WHEN e_bad_output THEN out_msg := 'Error 3 ...';
WHEN NO_DATA_FOUND THEN out_msg := 'Error 4 …';
WHEN OTHERS THEN out_msf := 'Error 5 ...';
RAISE;
end MY_SPROC;

Answer 1

>
Some other languages like ActionScript or C offer "import" or "include" commands that can be used to insert a code block to a function or procedure as if that block was typed exactly where it was imported or included
>
There is no equivalent of 'include'.
>
suppose I want to change the text description or error number in the exception
I wonder what others do in this situation?
>
One way is to use the RAISE_APPLICATION_ERROR procedure.
See Defining Your Own Error Messages (RAISE_APPLICATION_ERROR Procedure) in the PL/SQL Language doc
http://docs.oracle.com/cd/B28359_01/appdev.111/b28370/errors.htm#BABGIIBI
>
The RAISE_APPLICATION_ERROR procedure lets you issue user-defined ORA-n error messages from stored subprograms. That way, you can report errors to your application and avoid returning unhandled exceptions.
To invoke RAISE_APPLICATION_ERROR, use the following syntax:
raise_application_error(
error_number, message[, {TRUE | FALSE}]);
where error_number is a negative integer in the range -20000..-20999 and message is a character string up to 2048 bytes long. If the optional third parameter is TRUE, the error is placed on the stack of previous errors. If the parameter is FALSE (the default), the error replaces all previous errors. RAISE_APPLICATION_ERROR is part of package DBMS_STANDARD, and as with package STANDARD, you need not qualify references to it.
An application can invoke raise_application_error only from an executing stored subprogram (or method). When invoked, raise_application_error ends the subprogram and returns a user-defined error number and message to the application. The error number and message can be trapped like any Oracle Database error.
>
The error_number and message can be variables so for generalization you could define the actual list of each in the package spec and then reference them by variable name in the code.
So instead of
RAISE e_bad_input;
EXCEPTION
WHEN e_bad_input THEN out_msg := 'Error 1 …';You would code
-- package spec
gc_bad_input_number NUMBER := -20001;
gc_bad_input_message VARCHAR2(30) := 'Bad Input Message';
-- code in procedure
raise_application_error(gc_bad_input_number , gc_bad_input_message [, {TRUE | FALSE}]);Then you can change the message numbes and text used by changing the package spec and recompiling.
NOTE: If you change the package spec it will invalidate related objects and they will need to be recompiled. So this approach is suitable when deploying new code in a window when the system is not available for users.
An alternative is to create a table that contains the error numbers and messages and then load them into the package in the package body using the package level initialization section (a top-level block BEGIN). For that approach though the values might be loaded into an associative array where the key for each entry is the type of exception; for example 'bad_input'.
The RAISE_APPLICATION_ERROR would reference the associative array for 'error_number's by using 'bad_input' as the key and the text message array the same way.
The first approach hard-codes the codes and messages into the package spec so a code review can see them all.
The second approach is table-driven and indirect so by looking at the code you don't really know what the codes or messages are going to be.
Either approach could use a separate package spec dedicated to exception handling variables and declarations.
Is that more like what you had in mind?