Workflow in Error state in SWI1 tx, but still table is updating as usual, weird!!

Question

Hello,
We have a custom workflow, z_workflow.
In this z_workflow, its calling a custom FM, z_fm.
In this z_fm, I'm updating a custom tbale, z_table.
Before writing UPDATE z_table, I am locking this z_table by using 'ENQUEUE_E_TABLE', as below,
Pls. note this workflow is triggering in BACK GROUND by WF-BATCH user
CALL FUNCTION 'ENQUEUE_E_TABLE'
                  EXPORTING
                    mode_rstable   = 'E'
                    tabname        = 'Z_TABLE'
                  EXCEPTIONS
                    foreign_lock   = 1
                    system_failure = 2
                    OTHERS         = 3.
                IF sy-subrc = 0.
                  UPDATE z_table
                   SET matnr = ls_mara-matnr
                          descr = lv_text
                    WHERE ref_id = ref_id.
                  CALL FUNCTION 'DEQUEUE_E_TABLE'
                    EXPORTING
                      mode_rstable = 'E'
                      tabname      = 'Z_TABLE'.
                 ELSE.
                     MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                         WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. =====>
==> If the lock is failing an an ERROR / 'E' type message is occuring, but still the 'Rest of the code blocks' are executing normally (where in 2nd_z_table is updating), but the workflow is ending up in 'Error state' in SWI1 (workflow log) transaction, our users who are monitoring this workflow thinking that the transaction went bad, but again they noticed that the 2nd_z_table is updating as usual!!                         
                ENDIF.
                Rest of the code blocks ==> here another custom tbl, 2nd_z_table is updating
Our workflow expert said that, the error is occuring, well, but as its (z_fm) calling from / by back ground workflow user, hence the 'Rest of the code blocks' are triggering normally and the 2nd_z_table is updating as usual, but overall the workflow ends up in error state!
To avoide this confusing situation (workflow in error, but rest of the code blocks are executing normally), workflow expert suggested the below approach (raising of EXCEPTION in z_fm instead of ERROR message), pls. suggest me is it OK / safe / works good for me?
DO 10 TIMES. => Workflow expert asking me to add all these blue lines to my code
                CALL FUNCTION 'ENQUEUE_E_TABLE'
                  EXPORTING
                    mode_rstable   = 'E'
                    tabname        = 'Z_TABLE'
                  EXCEPTIONS
                    foreign_lock   = 1
                    system_failure = 2
                    OTHERS         = 3.
                IF sy-subrc = 0.
                  UPDATE z_table
                   SET matnr = ls_mara-matnr
                          descr = lv_text
                    WHERE ref_id = ref_id.
                  CALL FUNCTION 'DEQUEUE_E_TABLE'
                    EXPORTING
                      mode_rstable = 'E'
                      tabname      = 'Z_TABLE'.
                  CLEAR lv_locking_failed_on_z_table.
                  EXIT.
                ELSE.
                  WAIT UP TO 1 SECONDS.
                  lv_locking_failed_on_z_table = abap_true.
                ENDIF.
              ENDDO.
              IF lv_locking_failed_on_z_table IS NOT INITIAL.
                RAISE exception_lock_failed.  ===> Does the Raising EXCEPTION is solve my problem? pls. suggest me
                RETURN.
              ENDIF.
workflow expert said with this raising of exception will not trigger 'Rest of the code blocks' so that user will be not confused
Thank you

Answer 1

Hi "3SAP"
Yes, your WF guy is correct - raising exception will stall the workflow and not execute to the second table update.
Moreover, second table update logic should be kept inside of the SY-SUBRC = 0 of locking on FIRST TABLE update.
In current case, I cannot say for sure that second table is getting updated in the same call because as soon as TYPE 'E' message is triggered in a background step, standard exception is triggered in the workflow runtime to stop execution - which will NOT execute the code after MESSAGE statement.
As mentioned by Mike, the second table may have been updated from another instance/session/etc but from not this one.
Regards,
Modak