Fundamental exception handling irritation

Hello experts,

I have come across a very disturbing effect when using a function module capable of asynchronous execution in a <i>try-cleanup-endtry</i> statement. Please have a look at the following simple construct:

TRY.
    do_some_db_update( ).
    start_proc_chain_with_fm( ).
    COMMIT WORK.
  CLEANUP.
    ROLLBACK WORK.
ENDTRY.

The method <i>do_some_db_update( )</i> can raise an exception (when the update statement contained in it somehow fails). The method <i>start_proc_chain_with_fm( )</i> uses the fm <i>RSPC_API_CHAIN_START</i> to start some process chain, if it returns with return code <i>failed</i> we raise an exception too.

That is, both methods potentially raise exceptions. Obviously we only want to commit the involved DB changes if neither does and we want to roll back things if one of the two raises an exception (before propagating the exception to a caller).

Now, what happens occasionally ⚠️ is that the latter method fails, i.e. it actually raises an exception, however the programm flow executes both, the remaining code in the try-block (i.e. the COMMIT statement) <b>as well as</b> the CLEANUP-branch (i.e. the ROLLBACK statement, which of course has nothing to roll back by then anymore).

Can somebody please shed some light on this, I am very confused. This behavior upsets the very basis of my understanding of how exception handling in try-catch blocks works.

Of course I somehow suspect the function module's "asychronous" capabilities.. but actually I think this must not have an effect on the construction as such.

Regards,

Sebastian