Raising Exceptions Locate the document in its SAP Library structure

There are two options for raising class-based exceptions.

  1. System-driven raising in the runtime environment
  2. Program-driven raising in the ABAP program

Exceptions of the Runtime Environment

If error situations occur while ABAP statements are being executed in the ABAP runtime environment, exceptions that can be handled or cannot be handled are raised, depending on the error. The exceptions that can be handled are class-based and can be handled between TRY and ENDTRY. The associated exception classes are predefined in the system and begin with the prefix CX_SY_, such as CX_SY_ZERODIVIDE. In the ABAP keyword documentation, the exception classes whose exceptions may occur when a corresponding ABAP statement is executed are listed for each keyword. A typical example is the above class CX_SY_ZERODIVIDE, which can occur when an arithmetic expression is calculated in the COMPUTE statement. One or more runtime errors are assigned to each predefined exception class, depending on the cause of the error. The runtime errors only occur if the exception is not caught.

Exceptions in the ABAP Program

With error situations in the ABAP program, exceptions can be raised in a program-driven manner using the RAISE EXCEPTION statement. Exceptions based on both self-defined exception classes and on exception classes predefined in the system are possible here.

The RAISE EXCEPTION statement has two variants:

Raising an Exception With Generation of an Exception Object

The syntax is:

RAISE EXCEPTION TYPE cx_... [EXPORTING ... fi = ai ...].

This statement raises the exception linked to exception class cx_... and generates a corresponding exception object. The optional IMPORTING parameters of the instance constructor of the exception class can be supplied with the EXPORTING addition. This can fill the attributes of the object with values that a handler can access.

For reasons of efficiency, an exception object is only actually generated if the INTO addition of the CATCH statement is used for exception handling. For this reason, the constructor should not contain any further functionality, except for a function for initializing the attributes, and cannot be changed in global exception classes (only the constructor of a local exception class can contain further functionality).

Raising an Exception with an Existing Exception Object

The syntax is:

RAISE EXCEPTION ref.

In this case, the exception object must already exist and the REF reference variable must point to it. This may be the case if the exception has already been caught once but if the handler wants to raise it again (because it cannot be handled completely, for example) or if the exception object was generated previously by means of CREATE OBJECT.

Example

Example

report  DEMO_RAISE_EXCEPTIONS.

data OREF type ref to CX_ROOT.
data TEXT type STRING.

    try.
    try.
    raise exception type CX_DEMO_CONSTRUCTOR
          exporting MY_TEXT = SY-REPID.

  catch CX_DEMO_CONSTRUCTOR into OREF.
      TEXT = OREF->GET_TEXT( ).
    write / TEXT.
      raise exception OREF.
  endtry.
  catch CX_DEMO_CONSTRUCTOR into OREF.
      TEXT = OREF->GET_TEXT( ).
    write / TEXT.
endtry.

This example shows the two variants of the RAISE EXCEPTION statement. The first statement removes the self-defined exception of the class CX_DEMO_CONSTRUCTOR in the internal TRY block, generates the corresponding object, and transfers the program name to the instance constructor. In the internal CATCH block, the exception is handled, the exception text is output, and the exception is raised again without generating a new object. The external CATCH block handles the exception again. The class CX_DEMO_CONSTRUCTOR is defined in such a way that the transferred program name appears in the exception text. The generated instance constructor takes care of this.

 

 

Leaving content frame