Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Program Flow Logic →  Exception Handling →  Class-Based Exceptions →  TRY 


Quick Reference

Other versions: 7.31 | 7.40 | 7.54


CATCH [BEFORE UNWIND] cx_class1 cx_class2 ... [INTO oref]. 


2. ... INTO oref


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.


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.


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 ). 

    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( ) ). 

Executable Example

Exceptions, CATCH

Addition 1



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 the CATCH block, the context is deleted when the CATCH block is exited.
  • Of a RESUME statement is executed in the CATCH 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 of LEAVE 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 the CATCH block, but not in a procedure that is called in this block. This is because the context would be deleted if the CLEANUP 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 the CLEANUP blocks. However, if the system returns to the CATCH 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.


  • If addition BEFORE UNWINDis not specified, the context is deleted before the CATCH block is executed.
  • The statement RESUME can be used only when handling a resumable exception and only in a CATCH 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 the CATCH block is exited.
  • Resumable exceptions can also be handled in CATCH blocks without the addition BEFORE UNWIND. In this case, the context of the exception is deleted before the handling process and the statement RESUME cannot be specified.
  • Use of the addition BEFORE UNWIND for CATCH is only required when the statement RESUME 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 in CLEANUP blocks. This makes sense, for example, when handling resource bottlenecks if releasing resources in CLEANUP 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 a CATCH block, each MESSAGE statement that sends a message causes the runtime error EXCP_HANDLER_FAILED_TO_UNWIND.


Uses the addition BEFORE UNWIND when a resumable exception cx_demo is caught.

CLASS cx_demo DEFINITION INHERITING FROM cx_static_check. 


  METHOD meth. 
    cl_demo_output=>display( 'Resumed ...' ). 

      cls=>meth( ). 

Addition 2

... INTO oref


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 of oref; 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.


Within a CATCH block without the addition BEFORE UNWIND, the attribute IS_RESUMABLE of the exception object is undefined.


Catches exceptions with an inline declaration of an object reference variable. The static type of this variable is cx.



  CATCH cy cx INTO DATA(oref).