How to handle multiple save exceptions (Bulk Collect)

Question

Hi
How to handle Multiple Save exceptions? Is it possible to rollback to first deletion(of child table) took place in the procedure.
There are 3 tables
txn_header_interface(Grand Parent)
orders(parent)
order_items (Child)
One transaction can have one or multiple orders in it.
and one orders can have one or multiple order_items in it.
We need to delete the data from child table first then its parent and then from the grand parent table.if some error occurs anywhere I need to rollback to child record deletion. Since there is flag in child table which tells us when to delete data from database.
Is it possible to give name to Save exceptions?
e.g.
FORALL i IN ABC.FIRST..ABC.LAST SAVE EXCEPTIONS A
FORALL i IN abc.FIRST..ABC.LAST SAVE EXCEPTIONS B
if some error occurs then
ROLLBACK A; OR ROLLBACK B;
Please find the procedure attached
How to handle the errors with Save exception and rollback upto child table deletion.
CREATE OR REPLACE
PROCEDURE DELETE_CONFIRMED_DATA IS
TYPE TXN_HDR_INFC_ID IS TABLE OF TXN_HEADER_INTERFACE.ID%TYPE;
TXN_HDR_INFC_ID_ARRAY TXN_HDR_INFC_ID;
ERROR_COUNT NUMBER;
BULK_ERRORS EXCEPTION;
PRAGMA exception_init(bulk_errors, -24381);
BEGIN
SELECT THI.ID BULK COLLECT
INTO TXN_HDR_INFC_ID_ARRAY
FROM TXN_HEADER_INTERFACE THI,ORDERS OS,ORDER_ITEMS OI
WHERE THI.ID = OS.TXN_HDR_INFC_ID
AND OS.ID = OI.ORDERS_ID
AND OI.POSTING_ITEM_ID = VPI.ID
OI.DW_STATUS_FLAG =4 --data is moved to Datawarehouse
MINUS
(SELECT THI.ID FROM TXN_HEADER_INTERFACE THI,ORDERS OS,ORDER_ITEMS OI
WHERE THI.ID = OS.TXN_HDR_INFC_ID
AND OS.ID = OI.ORDERS_ID
OI.DW_STATUS_FLAG !=4);
IF SQL%NOTFOUND
THEN
EXIT;
END IF;
FORALL i IN TXN_HDR_INFC_ID_ARRAY.FIRST..TXN_HDR_INFC_ID_ARRAY.LAST SAVE
EXCEPTIONS
DELETE FROM ORDER_ITEMS OI
WHERE OI.ID IN (SELECT OI.ID FROM ORDER_ITEMS OI,ORDERS
OS,TXN_HEADER_INTERFACE THI
WHERE OS.ID = OI.ORDERS_ID
AND OS.TXN_HDR_INFC_ID = THI.ID
AND THI.ID = TXN_HDR_INFC_ID_ARRAY(i));
FORALL i IN TXN_HDR_INFC_ID_ARRAY.FIRST..TXN_HDR_INFC_ID_ARRAY.LAST SAVE
EXCEPTIONS
DELETE FROM ORDERS OS
WHERE OS.ID IN (SELECT OS.ID FROM ORDERS OS,TXN_HEADER_INTERFACE THI
WHERE OS.TXN_HDR_INFC_ID = THI.ID
AND THI.ID = TXN_HDR_INFC_ID_ARRAY(i));
FORALL i IN TXN_HDR_INFC_ID_ARRAY.FIRST..TXN_HDR_INFC_ID_ARRAY.LAST SAVE
EXCEPTIONS
DELETE FROM TXN_HEADER_INTERFACE THI
WHERE THI.ID = TXN_HDR_INFC_ID_ARRAY(i);
COMMIT;
DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSDATE, 'DD-MON-YY HH:MIPM')||':
DELETE_CONFIRMED_DATA: INFO:DELETION SUCCESSFUL');
EXCEPTION
WHEN OTHERS THEN
ERROR_COUNT := SQL%BULK_EXCEPTIONS.COUNT;
DBMS_OUTPUT.PUT_LINE(TO_CHAR(SYSDATE, 'DD-MON-YY HH:MIPM')||':
DELETE_CONFIRMED_DATA: ERROR:Number of errors is ' ||ERROR_COUNT);
FOR indx IN 1..ERROR_COUNT LOOP
DBMS_OUTPUT.PUT_LINE('Error ' || indx || 'occurred during
'||'iteration'||SQL%BULK_EXCEPTIONS(indx).ERROR_INDEX);
DBMS_OUTPUT.PUT_LINE('Error is '
||SQLERRM(-SQL%BULK_EXCEPTIONS(indx).ERROR_CODE));
END LOOP;
END DELETE_CONFIRMED_DATA;
Any suggestion would be of great help.
Thanks in advance
Anu

Answer 1

If you have one or two places in your code that need multiple exceptions, just do it with multiple catch statements. Unless you are trying to write the most compact Programming 101 homework program, inventing tricks to remove two lines of code is not good use of your time.
If you have multiple catches all over your code it could be a code smell. You may have too much stuff happening inside one try statement. It becomes hard to know what method call throws one of those exceptions, and you end up handling an exception from some else piece of code than what you intended. E.g. you mention NumberFormatException -- only process one user input inside that try/catch so it is easy to see what error message is given if that particular input is gunk. The next step of processing goes inside its own try/catch.
In my case, the ArrayIndexOutOfBoundsException and
NumberFormatException should be handled by the same way.Why?
I don't think I have ever seen an ArrayIndexOutOfBoundsException that didn't indicate a bug in the code. Instead of an AIOOBE perhaps there should be an if statement somewhere that prevents it, or the algorithm logic should prevent it automatically.