What does it do? The statement TRY> introduces a control structure with multiple statement blocks. The first statement block try_block> is always processed, whereas a branching off to exactly one of the remaining statement blocks only occurs if a class-based exception> is raised in try_block>. A TRY> control structure defines the following statement blocks:
A TRY> block try_block> directly after the statement TRY >. The TRY> block defines a protected area whose class-based exceptions can be handled in the subsequent CATCH> blocks. If no exception is raised in the TRY> block and it reaches its end, processing continues after ENDTRY>. If a class-based exception is raised in the TRY> block, the system searches for an exception handler in the same or an external TRY> control structure (see System Behavior>).
One or more optional CATCH> blocks catch_block> for handling exceptions, each directly after a CATCH>> statement. If the end of a CATCH> block is reached without being exited early, the processing continues after the ENDTRY>. The special statements RETRY>> and RESUME>> can be listed in a CATCH> block, to control the behavior of exception handling.
An optional CLEANUP> block cleanup_block> for cleanups directly after the CLEANUP>> statement. BEGIN_SECTION VERSION 5 OUT A TRY> control structure invalidates the simultaneous use of the obsolete statement CATCH SYSTEM-EXCEPTIONS>> to handle catchable runtime errors> in the current processing block>. END_SECTION VERSION 5 OUT
Latest notes:
All statement blocks of a TRY> control structure can contain any kind of control structures, in particular further TRY> control structures.
Since no exceptions can be propagated from the static constructors> and event handlers>, they must always be handled locally. An exception to this rule is exception category CX_NO_CHECK>, that can be propagated from event handlers. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Division by zero in a TRY> block. The relevant exception is caught with CATCH>>. ABEXA 00713 ABAP_EXAMPLE_END