Exceptions are way to communicate that something went wrong. An exception is a problem that arises during the execution of a program. When an exception occurs the normal flow of the program is disrupted and the program application terminates abnormally, which is not recommended, therefore these exceptions are to be handled.

ABAP exception handling is built upon three keywords − RAISE, TRY, CATCH and CLEANUP.

1. Raising Exceptions 

It is raised in the ABAP program. Let’s say we have a function module which takes 2 numbers and returns the difference. Lets say user does not enter the first number in such case we have to raise an exception saying the first number is required and until it is not supplied system will not be able to calculate the difference.

Below is a way to create an exception in the function module and call it in a program.

FUNCTION Z_TEST_1.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(IF_NUM1) TYPE  I
*"     REFERENCE(IF_NUM2) TYPE  I
*"  EXPORTING
*"     REFERENCE(EF_DIF) TYPE  I
*"  EXCEPTIONS
*"      NO_NUM
*"----------------------------------------------------------------------
if if_num1 is INITIAL.
MESSAGE e398(00) WITH 'num1 not supplied' RAISING no_num.
exit.
ENDIF.
ef_dif = if_num1 - if_num2.
ENDFUNCTION.

So function module Z_TEST_1 is created to calculate the difference of 2 numbers. Below is the report in which we are calling the function module and raising the exception in case first number is not entered.

*&---------------------------------------------------------------------*
*& Report  ZEXP_1
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT zexp_1.

START-OF-SELECTION.

  DATA : if_num1 TYPE i.
  DATA : if_num2 TYPE i.
  DATA : ef_dif TYPE i.

  if_num2 = 100.

  CALL FUNCTION 'Z_TEST_1'
    EXPORTING
      if_num1 = if_num1
      if_num2 = if_num2
    IMPORTING
      ef_dif  = ef_dif
    EXCEPTIONS
      no_num  = 1
      OTHERS  = 2.
  IF sy-subrc <> 0.
* Implement suitable error handling here
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
    WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.

2. Retrieve from exception repository

We can maintain exception in the transaction SE37 in the exceptions tab as shown below it can be populated dynamically using the FM  ‘SWO_TEXT_FUNCTION_EXCEPTION’

• 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 exceptin: 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.

So there are 2 kinds of exception, the one which we talked about is called non class- exceptions as classes are not involved

the other one is class based exceptions where exceptions occur in the classes/

1. Class based exceptions has to be catched using try catch and end try. Whenever an exception is triggered, an exception object is created
2. Within one TRY .. ENDTRY statement, we can have more than one CATCH statement.
3. Since all the exception classes are inherited from CX_ROOT, We can use the method GET_TEXT and GET_LONG_TEXT to know more about why exception was raised

All Exception classes are inherited from the global exception class’s CX_ROOT these subclasses

CX_STATIC_CHECK

If the exception is defined as a subclass of CX_STATIC_CHECK, it has to be declared in the method or FM signature. If the exception is not declared, it has to be caught. If not caught neither declared, it would result into run-time error

CX_DYNAMIC_CHECK

If the exceptions are inherited from CX_DYNAMIC_CHECK, it needs to be declared in the FM signature. Generally, all system exceptions like CX_SY_ZERO_DIVIDE begins with CX_SY. All of them are inherited from CX_DYNAMIC_CHECK.

CX_NO_CHECK

Exceptions that are defined using subclasses of CX_NO_CHECK must not be declared explicitly in the interface of the procedure.

Below is an example for class based example simple example

REPORT test.

PARAMETERS : p1 TYPE i,
             p2 TYPE i.

CLASS test_exp DEFINITION.
  PUBLIC SECTION.
    METHODS : mul IMPORTING in1        TYPE i
                            in2        TYPE i
                  RETURNING VALUE(en3) TYPE i
                  RAISING   cx_sy_arithmetic_overflow,
      display.
  PRIVATE SECTION.
    DATA : n1 TYPE i,
           n2 TYPE i,
           n3 TYPE i.
ENDCLASS.

CLASS test_exp IMPLEMENTATION.
  METHOD mul.
    n1 = in1.
    n2 = in2.
    n3 = in1 * in2.
    en3 = n3.
  ENDMETHOD.

  METHOD display.
    WRITE : / n1,'*',n2,'=',n3.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
  DATA : obj  TYPE REF TO test_exp,
         ref  TYPE REF TO cx_sy_arithmetic_overflow,
         text TYPE string.
  CREATE OBJECT obj.
  CREATE OBJECT ref.
  TRY.
      obj->mul( in1 = p1
      in2 = p2 ).
      obj->display( ).
    CATCH cx_sy_arithmetic_overflow INTO ref.
      text = ref->get_text( ).
      MESSAGE text TYPE 'E'.
  ENDTRY.

The steps associated in exception handling with Exception class are,
Ø      Raise Class Based Exception

Ø      Exception Object Creation

Ø      Handling the Exception

Raise Class Based Exception

 METHODs : mul IMPORTING in1 TYPE I
in2 TYPE I
RETURNING VALUE(en3) TYPE I
RAISING cx_sy_arithmetic_overflow,

Exception Object Creation

DATA : obj TYPE REF TO test_exp,
ref TYPE REF TO cx_sy_arithmetic_overflow,
text TYPE string.
CREATE OBJECT obj.
CREATE OBJECT ref.

Handling the Exception

TRY.
obj->mul( in1 = p1
in2 = p2 ).
obj->display( ).
CATCH cx_sy_arithmetic_overflow INTO ref.
text = ref->get_text( ).
MESSAGE text TYPE 'E'.
ENDTRY.

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.

A wrapper program is simply a program that runs another program. you don’t need to include the original screen because you may be able to simplify it. You may or may not want to do some of the validations that are done in the submitted program.

The “wrapper” does some additional work like additional authority check, restriction of data selection, pre-populating selection values, extracting some data to pass on to the actual standard program.

How to use messages from messages repository

1. you need to include the interface IF_T100_MESSAGE in the exception class