Fundamental exception handling irritation

[Former Member]

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

[matt]

Some thoughts:

Put a CLEANUP INTO oref, and look at the values of the oref. It may give a clue?

Is RSPC_API_CHAIN_START running asynchronously as well?

As a work-around, could you put the db_update and commit work into the process chain? ( Perhaps create your own process type, so you can have an ABAP that makes a decision - this is very easy to do ).

matt

[Former Member]

Hi Matt,

thanks for you answer. The exception thrown is indeed my <i>chain_start_failed_ex</i> (my class-based wrapper around/equivalent of the original <i>failed</i>-"exception" returned by the function module). That is, an exception is thrown and the programm flow should definitly continue after the CLEANUP statement. However, this is not always the case.

As for your proposal this could be a work-around for the concret problem. Nevertheless I would very much like to find a general explanation for this "mystery". In principle I think - regardless of what the methods actually do - the effect discribed should never happen..

Regards,

Sebastian

[matt]

I strongly suggest that you think about raising this with SAP through oss.

Do you get the same results (occassionally!) if you don't call the fm, but simply raise the exception chain_start_failed in your wrapper class?

The process chain FM, IIRC, runs asynchronously, so perhaps it's behaviour is having some impact on the try...

frankly, I'm deeply puzzled!

matt

[Former Member]

Hi Matt, in a way I am glad that someone (you) is puzzled too Maybe I should open a call..

Regards,

Sebastian