In continuation to previous post on Raising & Handling Non-class based exceptions, lets see the message addition RAISING along with the overall flow control.

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

Message RAISING

When we raise the exception by statement RAISE, it doesn’t provide us the default details. If we are interested in providing default message to the caller we need to use MESSAGE RAISING statement. This would set the correspdoing message parameters (MSGNO, MSGID, MSGV1, etc.) of SYST from the actual message raised. Caller can directly produce this message or can overwrite with another error processing based on the requirement.

 
FUNCTION ztest_np_exception_raising.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(IV_NUM1) TYPE  I OPTIONAL
*"     REFERENCE(IV_NUM2) TYPE  I OPTIONAL
*"  EXPORTING
*"     REFERENCE(CV_OUT) TYPE  I
*"  EXCEPTIONS
*"      MANDATORY_PARAM_MISSING
*"      CROSSED_LIMIT
*"----------------------------------------------------------------------
 
  IF iv_num1 IS INITIAL
  OR iv_num2 IS INITIAL.
*   RAISE mandatory_param_missing.
    MESSAGE e398(00) WITH 'Mandatory Parameters are missing'
      RAISING mandatory_param_missing.
  ENDIF.
  PERFORM f_do_calculation USING iv_num1 iv_num2
                           CHANGING cv_out.
 
ENDFUNCTION.
 

On exception handling part, all the message variables are set from the message statement.

 
DATA: lv_num1 TYPE i VALUE '90'.
DATA: lv_res  TYPE i.
CALL FUNCTION 'ZTEST_NP_EXCEPTION_RAISING'
  EXPORTING
    iv_num1                 = lv_num1
  IMPORTING
    cv_out                  = lv_res
  EXCEPTIONS
    mandatory_param_missing = 1
    crossed_limit           = 2
    OTHERS                  = 3.
IF sy-subrc <> 0.
  MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
          WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ELSE.
  WRITE:/ lv_res.
ENDIF.
 

In a nutshell

Whenever an Exception is raised, this is how system will behave:

In words…

• If FM or method raises an exception and caller has set a return value to the exception: Processing of the FM / method would be terminated and SY-SUBRC would be set. This would also include setting value to OTHERS.
• If FM or method raises an exception and caller hasn’t set a return value to the exceptino: Processing would be terminated with runtime error – RAISE_EXCEPTION
• If exception has been raised from any other subroutine or include, system would try to corelate it with the First FM’s exceptions. If match is found, system would treat the exception as it raised from FM. Based on caller’s behavior, return value would be set or runtime error will occur.
• In all other scenarioes, runtime error RAISE_EXCEPTION would occur.

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