This is kind of a question about best practices. I have a PL/SQL block similar to this
DECLARE
--work variables
PROCEDURE p1(in_parameter1, out_parameter1, out_parameter2...) IS
BEGIN
--do stuff
--select ( ... ) into ( ... ) from t1 where ( ... )
END;
PROCEDURE p2(in_parameter1, out_parameter1, out_parameter2...) IS
BEGIN
--do stuff
--insert/update tables
--do more stuff
END;
BEGIN -- MAIN PROCESS STARTS HERE
open c1;
fetch c1 into c1RowData;
EXIT WHEN c1%NOTFOUND
--call procedure1
--do stuff
--call procedure2
--do stuff
--do stuff
--call procedure1
--call procedure2
END;
/
EXIT;
The statements in procedures p1 and p2 could possibly raise exceptions ( NO_DATA_FOUND, DUP_VAL_ON_INDEX, … ).
What do you think is the best way to handle this exceptions? Should they be handled inside the procedures or do you think that I should surround every call the procedures in the main body with a TRY-CATCH block?
Personally I’d catch them inside the procedures they’re thrown from. This means that you have much more control with regards to how they’re handled externally. For example, you can throw them again as user defined exceptions which you can embellish with more information about exactly what went wrong.
is much more descriptive outside the procedure than
But this is realy dependent on:
For example, say you wanted to run procedure 2 even though the select in procedure 1 found no rows.. You’d need to catch the exception in procedure 1 and ignore it. If you didn’t, then it’d be thrown to the exception handler in procedure 2.
Or, say you wanted procedure 1 to insert a row in the case where the select didn’t find anything, in this case you’d need to catch the exception and perform the insert in the exception handler.
Now, before anyone jumps on me, I’m not recommending you use exception handlers for contrlling the flow of execution within your code, these examples are the theoretical, but hopefully you get the idea..