Exceptions are way to communicate effectiently to the caller about something went wrong. So, the caller of the FM or method, would process them accordingly.

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

Before we begin understanding the non-class based exception, a note: As on 6.10, class based exceptions are introduced. These class based exceptions should be used instead of these self-defined treatable exceptions. We’ll see more about the class based exception in next posts.

In continuation to one of my old post Function Module Exception Handling, today we’ll check some more options.

Defining Exception

Non-class based exceptions are only allowed to be declared in the signature of the Function Module and Methods. While defining FM or method, we can specify the exceptions in the exception tab. Here you can specify exception ID and exception text.

For the demo purpose, I have created a FM with two exceptions:

• MANDATORY_PARAM_MISSING – Mandatory Parameter Missing
• CROSSED_LIMIT – Crossed Limit

 
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.
  ENDIF.
  PERFORM f_do_calculation USING iv_num1 iv_num2
                           CHANGING cv_out.
 
ENDFUNCTION.
*
FORM f_do_calculation USING pv_num1 TYPE i
                            pv_num2 TYPE i
                      CHANGING cv_out TYPE i.
  cv_out = pv_num1 + pv_num2.
  IF cv_out GE 100.
    RAISE crossed_limit.
  ENDIF.
ENDFORM.                    "f_do_calculation
 

In the code, we can use the statement RAISE excetpion_id to raise the exception and let the caller know that something is wrong. Like, I use RAISE MANDATORY_PARAM_MISSING when one of the importing parameter is blank.

I also have raised the exception CROSSED_LIMIT from the Subroutine F_DO_CALCULATION. When we raise an exception within the Subroutine, system would try to corelate it with the First FM in the callstack. If it find a match, it would treat this exception as if it was raised from the FM itself.

Handling the Exceptions

To handle the non-class based exceptions, we need to assign the retunr code value to the exception. If the return code value is not assigned, it would result into the short-dump.

 
DATA: lv_num1 TYPE i.
CALL FUNCTION 'ZTEST_NP_EXCEPTION_RAISING'
  EXPORTING
    iv_num1                 = lv_num1
  EXCEPTIONS
    mandatory_param_missing = 1
    crossed_limit           = 2
    OTHERS                  = 3.
IF sy-subrc <> 0.
  WRITE: 'Exception occured'.
ELSE.
  WRITE: 'No exception'.
ENDIF.
 

Using OTHERS:
When we are not interested in the details of the exceptions, we can simply set all the exceptions to a return code using OTHERS. So, whenever any exception would raise, this return code would be set to SY-SUBRC. Based on the value, we can write error handling logic.

 
DATA: lv_num1 TYPE i.
CALL FUNCTION 'ZTEST_NP_EXCEPTION_RAISING'
  EXPORTING
    iv_num1                 = lv_num1
  EXCEPTIONS
    OTHERS                  = 3.
IF sy-subrc <> 0.
  WRITE: 'Exception occured'.
ELSE.
  WRITE: 'No exception'.
ENDIF.
 

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