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
RESUME
statement is executed in theCATCH
block, the context is deleted when theCATCH
block is exited. -
Of a
RESUME
statement is executed in theCATCH
block, 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 ofLEAVE
are 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
CLEANUP
blocks 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
CATCH
block. For example,LEAVE TO TRANSACTION
can be executed directly in theCATCH
block, but not in a procedure that is called in this block. This is because the context would be deleted if theCLEANUP
blocks are not executed. -
If the message type is
dynamically specified for the
MESSAGE
statement 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 theCLEANUP
blocks. However, if the system returns to theCATCH
block 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 UNWIND
is not specified, the context is deleted before theCATCH
block is executed. -
The statement
RESUME
can be used only when handling a resumable exception and only in aCATCH
block in which the addition BEFORE UNWIND is specified. This is the only case in which the context of the exception is not deleted when theCATCH
block is exited. -
Resumable exceptions can also be handled in
CATCH
blocks without the additionBEFORE UNWIND
. In this case, the context of the exception is deleted before the handling process and the statementRESUME
cannot be specified. -
Use of the addition
BEFORE UNWIND
forCATCH
is only required when the statementRESUME
is used. However, it is allowed in principle during exception handling if the context of the exception is to be evaluated before any cleanup activities inCLEANUP
blocks. This makes sense, for example, when handling resource bottlenecks if releasing resources inCLEANUP
blocks 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 UNWIND
during aCATCH
block, eachMESSAGE
statement 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.