ABAP Keyword Documentation → ABAP − Reference → Program Flow Logic → Exception Handling → Class-Based Exceptions → TRY
CATCH
Other versions: 7.31 | 7.40 | 7.54
Syntax
CATCH [BEFORE UNWIND] cx_class1 cx_class2 ... [INTO oref].
Extras
1. ... BEFORE UNWIND
2. ... INTO oref
Effect
Introduces a CATCH block of a TRY control structure in which exceptions can be handled.
A CATCH block is an exception handler, meaning the program logic that is
executed whenever the associated exception is raised in the TRY block of the same TRY control structure.
A CATCH block handles the exceptions of the exception classes cx_class1
cx_class2 ... that are specified after the statement CATCH as well
as the exceptions of the subclasses of these exception classes. In each CATCH
statement of a TRY control structure, any number of exception classes
cx_class1 cx_class2 ... can be specified, with more specific exception classes (subclasses) being
specified before more general exception classes (superclasses). This order must be preserved both within
a CATCH statement and across multiple CATCH statements of a TRY control structure.
Before the CATCH block is executed, the system by default deletes the context
in which the exception was raised. To preserve the context during execution of the CATCH block, the BEFORE UNWIND addition can be used.
Note
The rule where special exception classes must be specified before general classes in CATCH
ensures that an exception is not handled by a general exception handler (superclass) if a special handler (subclass) is provided.
Example
Catch two possible exceptions with CATCH. If the input cannot be interpreted
as number, the exception CX_SY_CONVERSION_NO_NUMBER is caught by its superclass CX_SY_CONVERSION_ERROR. If the number 0 is entered, the exception CX_SY_CONVERSION_ERROR is caught by its superclass CX_SY_ARITHMETIC_ERROR.
DATA(input) = `x`.
cl_demo_input=>request( CHANGING field = input ).
TRY.
cl_demo_output=>display( |{ 1 / CONV decfloat34( input ) }| ).
CATCH cx_sy_arithmetic_error cx_sy_conversion_error INTO DATA(exc).
cl_demo_output=>display( exc->get_text( ) ).
ENDTRY.
Executable Example
Addition 1
... BEFORE UNWIND
Effect
If the addition BEFORE UNWIND is specified, the context in which the exception
was raised is not deleted until the CATCH block is deleted. Instead, the
context is preserved (including all called procedures and their local data) during the execution of the CATCH block.
-
If no
RESUMEstatement is executed in theCATCHblock, the context is deleted when theCATCHblock is exited. -
Of a
RESUMEstatement is executed in theCATCHblock, processing resumes after the place that raised the exception.
Any CLEANUP blocks are always
executed directly before their context is deleted. If BEFORE UNWIND is used,
after exception handling, and in all other cases before the exception handling. In a CATCH
block with BEFORE UNWIND, no statements can be executed in which the context is closed without executing any CLEANUP blocks.
-
The statements
CALL TRANSACTION,CALL DIALOG,SUBMIT,STOP,REJECT,CHECK SELECT-OPTIONS, and the obsolete variant ofLEAVEare forbidden, as they might leave the internal session. -
Statements such as LEAVE TO
TRANSACTION, which are statically known to leave the internal session, are permitted. In
such cases, exception handling is correctly ended while executing the
CLEANUPblocks before the statement is executed. -
Procedure calls are allowed. However, if the context is deleted during this type of procedure call,
a runtime error occurs EXCP_HANDLER_FAILED_TO_UNWIND. This is also the case if a statement is executed
here, which is allowed in the
CATCHblock. For example,LEAVE TO TRANSACTIONcan be executed directly in theCATCHblock, but not in a procedure that is called in this block. This is because the context would be deleted if theCLEANUPblocks are not executed. -
If the message type is
dynamically specified for the
MESSAGEstatement for sending messages, the ABAP runtime environment behaves as if exception handling is going to be exited. The context is deleted during the execution of theCLEANUPblocks. However, if the system returns to theCATCHblock after the MESSAGE statement has been executed (which can be the case with message types I and S, for example), the exception CX_SY_ILLEGAL_HANDLER is raised.
When combined with INTO, the addition BEFORE UNWIND
sets the attribute IS_RESUMABLE of the exception object and of the preceding exception objects in a
chaining with the attribute PREVIOUS. Up until the first resumable raised exception, IS_RESUMABLE is set to the value of ABAP_TRUE and is otherwise set to the value of ABAP_FALSE.
Notes
-
If addition
BEFORE UNWINDis not specified, the context is deleted before theCATCHblock is executed. -
The statement
RESUMEcan be used only when handling a resumable exception and only in aCATCHblock in which the addition BEFORE UNWIND is specified. This is the only case in which the context of the exception is not deleted when theCATCHblock is exited. -
Resumable exceptions can also be handled in
CATCHblocks without the additionBEFORE UNWIND. In this case, the context of the exception is deleted before the handling process and the statementRESUMEcannot be specified. -
Use of the addition
BEFORE UNWINDforCATCHis only required when the statementRESUMEis used. However, it is allowed in principle during exception handling if the context of the exception is to be evaluated before any cleanup activities inCLEANUPblocks. This makes sense, for example, when handling resource bottlenecks if releasing resources inCLEANUPblocks would change the context and thus make the calculation of the free resources in the exception handler meaningless. Other than for logging purposes, we do not recommend evaluating the part of the context that is only of interest locally for implementing the incorrect procedure. -
In a procedure called up using
BEFORE UNWINDduring aCATCHblock, eachMESSAGEstatement that sends a message causes the runtime error EXCP_HANDLER_FAILED_TO_UNWIND.
Example
Uses the addition BEFORE UNWIND when a resumable exception cx_demo is caught.
CLASS cx_demo DEFINITION INHERITING FROM cx_static_check.
ENDCLASS.
CLASS cls DEFINITION.
PUBLIC SECTION.
CLASS-METHODS meth RAISING RESUMABLE(cx_demo).
ENDCLASS.
CLASS cls IMPLEMENTATION.
METHOD meth.
...
RAISE RESUMABLE EXCEPTION TYPE cx_demo.
cl_demo_output=>display( 'Resumed ...' ).
...
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
TRY.
cls=>meth( ).
CATCH BEFORE UNWIND cx_demo.
RESUME.
ENDTRY.
Addition 2
... INTO oref
Effect
If the addition INTO is specified, a reference to the exception object is saved to oref. The following can be specified for oref:
-
An existing object reference variable
oref, whose static type must be more general or as general as the most general of the specified exception classes. -
An inline declaration with
DATA(var). The static type of the declared object reference variable is the exception class (if specified). If multiple exception classes are specified and a common superclass of these classes is used, the superclass is the static type oforef; if not, it is CX_ROOT.
The object reference variable can be used to access the attributes and methods of the exception object.
If the exception was raised with RAISE
RESUMABLE EXCEPTION and the addition BEFORE UNWIND was specified,
the attribute IS_RESUMABLE of the current exception object and of any preceding exception objects referenced
in the attribute PREVIOUS is, up until the first resumable raised exception, set to the value of ABAP_TRUE. In all other exception objects, the attribute IS_RESUMABLE is set to the value of ABAP_FALSE.
Note
Within a CATCH block without the addition BEFORE UNWIND, the attribute IS_RESUMABLE of the exception object is undefined.
Example
Catches exceptions with an inline declaration of an object reference variable. The static type of this variable is cx.
CLASS cx DEFINITION INHERITING FROM cx_dynamic_check.
PUBLIC SECTION.
ENDCLASS.
CLASS cy DEFINITION INHERITING FROM cx.
PUBLIC SECTION.
ENDCLASS.
TRY.
...
CATCH cy cx INTO DATA(oref).
ENDTRY.