Lets continue exploring more about Class based exceptions by checking out the runtime flow when an exception is being raised.

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

Flow

.. with code lines

To understand it better we’ll use the demo example of Class-based Exceptions I – Basics. I have given the related code snippets here. It would be useful to compare both of the code snippets to understand, how system is behaving.

• If raised exception is not being propagated in the call stack for (CX_STATIC_CHECK & CX_DYNAMIC_CHECK exceptions) till a TRY..ENDTRY block, it would result into Runtime error. Like in Demo, if the LCX_MANDATORY_MISSING was not specified in the method CALCULATE, it would result in run-time error.

Missing exception declaration

 
*
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
                     RAISING   "lcx_mandatory_missing   --- Commented - result in dump
                               cx_sy_arithmetic_error.
 

• In case of exception, system would try to find corresponding TRY .. ENDTRY block in the call hierarchy. If it doesn’t find any, it would result in Short-dump. Like in the demo, if the method CALCULATE would be called directly without TRY..ENDTRY it would result in short dump.

Without TRY block

 
* Runtime error .. as TRY..ENDTRY commented
  CREATE OBJECT lo_obj.
*  TRY .
      lo_obj->calculate( iv_num1 = 10 ).
*    CATCH lcx_mandatory_missing.
*      WRITE: /  'Mandatory Parameter is missing'.
*    CATCH CX_ROOT INTO lo_exc_root.
*      lv_msg = lo_exc_root->get_text( ).
*      WRITE: / lv_msg.
*  ENDTRY.
 

• If a TRY..ENDTRY block with specific exception being caught using CATCH excpetion_id, system would be successfully able to handle the exception. Whenever INTO addition is specified, instance of an exception object would be generated. In demo application, exception LCX_MANDATORY_MISSING is an example.

Exact exception handler

 
  TRY .
      lo_obj->calculate( iv_num1 = 10 ).
*   Exception is handled with itself
    CATCH lcx_mandatory_missing.
      WRITE: /  'Mandatory Parameter is missing'.
  ENDTRY.
 

• If a TRY..ENDTRY block with generic exception being caught using CATCH exception_id, exception would be handled successfully. In demo, exception CX_ROOT is handled this way. This code lines will raise CX_SY_ZERO_DIVIDE, but CX_ROOT is being handled.

Exception handling using super class

 
  TRY .
* Passed IV_NUM2 as 0 to get an exception
      lo_obj->calculate( iv_num1 = 10 iv_num2 = 0 ). 
*   Exception is handled with itself
    CATCH CX_ROOT INTO lo_exc_root.
      lv_msg = lo_exc_root->get_text( ).
      WRITE: / lv_msg.
  ENDTRY.
 

• If a CLENUP block is specified, within an inner block of TRY…ENDTRY, it would gets executed, before sending control back to the caller. More on CLEANUP in coming post.

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