Class-Based Exceptions in Asynchronous RFC

If you use an RFC call of type aRFC (asynchronous RFC) with a response (RECEIVE RESULTS FROM FUNCTION), the transfer of the exception object to the RFC client is different from the remaining RFC types in the following ways:

• The EXCEPTIONS block in the RECEIVE RESULTS FROM FUNCTION application is then always permitted when the corresponding CALL FUNCTION application also contains an EXCEPTIONS block. Likewise, the EXCEPTIONS block can then only be left out when this happens in both statements. The check is executed at runtime.

  Note

  Any alternative use of the EXCEPTIONS block can cause a runtime error. Since the assignment of both of the statements is not unique, syntax checks are not supported.

• If the function call is implemented without the EXCEPTIONS block, the callback routine is to be implemented as the method (referenced using the CALLING addition).

• The class-based exception can be caught using TRY...CATCH...ENDTRY if the statement RECEIVE RESULTS FROM FUNCTION is contained in this block (or in methods/forms that are called in this block).

• Class-based exceptions must be caught and handled within the callback routine and cannot be propagated to the outside. Every uncaught exception causes the runtime error UNCAUGHT_EXCEPTION.

• If the class-based exception handling is active and the statement RECEIVE RESULTS FROM FUNCTION is missing in the callback routine, then a runtime error is returned.

  Note

  These remarks do not need to be taken into consideration for RFC types with asynchronous properties (aRFC without response, tRFC, qRFC, bgRFC) because:

  • Exceptions are not transported to the RFC client for aRFC without response.

  • the client program does not contain the response for tRFC, qRFC, and bgRFC, rather the RFC layer itself executes the handling of all error situations (for both classic and class-based exceptions).