In the series of Class based Exceptions, lets check out the addition CLEANUP within the TRY..ENDTRY block.

Checkout all post related to Exception Raising & handling:

• Function Module Exception Handling
• Raising & Handling Non-class based exceptions – I
• Raising & Handling Non-class based exceptions – II
• Class-based Exceptions I – Basics
• Class-based Exceptions II – Design Time consideration
• Class based Exceptions III – Runtime flow
• Class based Exceptions IV – CLEANUP
• Exception class to use Messages from T100
• Why NOT to have a wrapper around Exception (RAISE) ?

TRY .. ENDTRY block also should have a CLEANUP block. This code block should contain cleaning up activity before leaving the TRY .. ENDTRY block. This block would gets triggered whenever there is no CATCH statement declared for the triggered exception in the current code block but it the exception is being caught somewhere else. So, if there isn’t any CATCH statment declared in the call hierarchy and the exception occurred, CLEANUP won’t get executed and it will result in the short-dump.

CLEANUP block would be used to remove the references before leaving the method call. Whenever exception occurs, system would stop processing from that point and go to the corresponding TRY block. Because of this behavior, object would be in intermediate state. CLEANUP block provides us an opportunity to restore the object state before leaving the current processing block.

Refer to the Class based Exceptions III – Runtime flow for flow diagram – look for right bottom corner for CLEANUP block processing.

Code Lines

Lets try to understand this with help of example:

 
report znp_demo_excep_cleanup.
*
CLASS lcx_mandatory_missing DEFINITION
  INHERITING FROM cx_static_check.
ENDCLASS.                    "lcx_mandatory_missing  DEFINITIO
 
*
CLASS lcl_test_exceptions DEFINITION.
  PUBLIC SECTION.
    METHODS: calculate IMPORTING iv_num1 TYPE i OPTIONAL
                               iv_num2 TYPE i OPTIONAL
                     RETURNING value(rv_calc) TYPE i.
  PRIVATE SECTION.
    METHODS: do_div.
    DATA: v_num1 TYPE i,
          v_num2 TYPE i,
          v_result TYPE i.
ENDCLASS.                    "lcl_test_exceptions DEFINITION
*
CLASS lcl_test_exceptions IMPLEMENTATION.
  METHOD calculate.
    v_num1 = iv_num1.
    v_num2 = iv_num2.
    me->do_div( ).
    rv_calc = v_result.
  ENDMETHOD.                    "calculate
  METHOD do_div.
    TRY.
        v_result = v_num1 DIV v_num2.
* This CLEANUP block would trigger as we catch all the
* exceptions using the CX_ROOT in the TRY .. ENDTRY 
* within START-OF-SELECTION.
      CLEANUP.
        CLEAR v_result.
    ENDTRY.
  ENDMETHOD.                    "do_sum
ENDCLASS.                    "lcl_test_exceptions IMPLEMENTATION
 
START-OF-SELECTION.
  DATA: lo_obj TYPE REF TO lcl_test_exceptions.
  CREATE OBJECT lo_obj.
  TRY .
      lo_obj->calculate( iv_num1 = 10 ).
    CATCH cx_root.
  ENDTRY.
 

In this example, we have an “outer” TRY..ENDTRY block in the START-OF-SELECTION. We have an “inner” TRY..ENDTRY block within the method CALCULATE( ) which is begin called from the outer block. Since we are not passing IV_NUM2, the devide statement will raise an exception type CX_SY_ZERODIVIDE. Since we are catching all the exception using CATCH CX_ROOT in the outer TRY block, system will execute the logic of CLEANUP block within inner TRY block.

Replace this CX_ROOT with CX_SY_BUFFER_OVERFLOW which is not part of the hierarchy of CX_SY_ZERODIVIDE thus CLEANUP wont get execute and it will result in run-time error.

Further Reading

Checkout all post related to Exception Raising & handling:

• Function Module Exception Handling
• Raising & Handling Non-class based exceptions – I
• Raising & Handling Non-class based exceptions – II
• Class-based Exceptions I – Basics
• Class-based Exceptions II – Design Time consideration
• Class based Exceptions III – Runtime flow
• Class based Exceptions IV – CLEANUP
• Exception class to use Messages from T100
• Why NOT to have a wrapper around Exception (RAISE) ?