CATCH - Catching Runtime Errors

Syntax

CATCH SYSTEM-EXCEPTIONS except1 = rc1 ... exceptn = rcn.

Effect

You can catch catchable runtime errors in the processing block enclosed between the CATCH and ENDCATCH statements.

Note the following:

rc ... rcn must be numeric literals.

You can include a CATCH ... ENDCATCH block anywhere where an IF ... ENDIF block can be included - that is, local to an event, not cross-event

The block can be nested to any depth

Exceptions will only be caught in the current call level. For example, PERFORM or CALL FUNCTION statements within a CATCH...ENDCATCH block will not be executed.

You can only use CATCH...ENDCATCH if you are not already using the class-based exceptions mechanism in the same context - that is within the same method, subroutine, function module, or ABAP event.

Specifying the catchable runtime error:

except1 ... exceptn can be any of the following:

• The identifier of the catchable runtime error - for example, CONVT_NO_NUMBER. You can only use a pre-defined name here. You cannot use the corresponding exception classes of the class-based solution.
  

One of the pre-defined exception groups, in which catchable runtime errors are summarized. You cannot use abstract exception classes here either.

OTHERS, all remaining catchable SYSTEM-EXCEPTION runtime errors. If you declare OTHERS, it must be as the last SYSTEM-EXCEPTION in the list.

Catchable runtime errors are assigned to exception groups. If you specify an exception group, all runtime errors included in this group will be caught. All catchable runtime errors are caught in OTHERS.

Keyword dependency

Certain runtime errors can only be caught using pre-defined keywords in the CATCH ... ENDCATCH block.

For information on which keywords can catch a specific runtime error, refer to:

The keyword documentation, where catchable runtime errors are declared explicitly

Exception groups

If a runtime error is caught

If a runtime error is caught, the current processing block is interrupted, and the system jumps from the ABAP statement where the error occurred to the appropriate ENDCATCH statement - regardless of how many control structure levels (IF, DO, LOOP, SELECT, CATCH!, etc, ...) must be skipped.
You cannot be certain of the content of the fields affected by a statement where an error occurred, after ENDCATCH.

Return Value

After the appropriate ENDCATCH statement, SY-SUBRC is set to the "rcn" value assigned to the runtime error or to the corresponding ERROR group in the CATCH statement. If there is more than one " exceptn = rcn" expression in which the runtime error has been (implicitly) declared, the system returns the "rcn" value of the first expression. This is particularly significant if two different exception groups, both containing the same runtime errors, have been declared.

If no runtime error is caught, SY-SUBRC contains the value 0 after the appropriate ENDCATCH statement has been executed.

Example

Nested Structures
The following example program calculates the factorial of the program parameter "fact". If the value of "fact" is too large, the runtime error COMPUTE_BCD_OVERFLOW is caught. In this case, the system leaves the current DO...ENDDO loop directly at the MULTIPLY statement and skips to the ENDCATCH statement.

PARAMETERS fact TYPE i.
DATA: fact_save TYPE i,
      res(16)  TYPE p.
*** ARITHMETIC_ERRORS contains COMPUTE_BCD_OVERFLOW ***
CATCH SYSTEM-EXCEPTIONS ARITHMETIC_ERRORS = 5.
  res = fact_save = fact.
  SUBTRACT 1 FROM fact.
  DO fact TIMES.
    MULTIPLY res BY fact. "<- COMPUTE_BCD_OVERFLOW
    SUBTRACT 1 FROM fact.
  ENDDO.
ENDCATCH.
IF sy-subrc = 5.
  WRITE: / 'Overflow! Factorial of', fact_save,
                               'cannot be calculated.'.
ELSE.
  WRITE: / 'Factorial of', fact_save, 'gives', res.
ENDIF.

Examples

Keyword dependency

The first example catches the runtime error CONVT_NO_NUMBER during a conversion using the MOVE statement.

In the second example, the runtime error cannot be caught, since the keyword SELECT has no conversion function.

In the third example, the conversion is moved to an auxiliary field (MOVE 'abc' TO int.) Only operands of the same type are used in the SELECT statement. Runtime errors can be caught in this way.

DATA I TYPE I.
*** CONVERSION_ERRORS contains CONVT_NO_NUMBER ***
CATCH SYSTEM-EXCEPTIONS CONVERSION_ERRORS = 1.
  MOVE 'abc' TO I.          " <- Error: CONVT_NO_NUMBER
ENDCATCH.
IF SY-SUBRC = 1.
  ...
ENDIF.
...

DATA SFLIGHT_WA TYPE SFLIGHT.
CATCH SYSTEM-EXCEPTIONS CONVERSION_ERRORS = 1.
    INTO SFLIGHT_WA
    WHERE SEATSMAX = 'abc'. " <- Error: CONVT_NO_NUMBER
   ...
  ENDSELECT.
ENDCATCH.
...

DATA SFLIGHT_WA TYPE SFLIGHT.
DATA int LIKE SFLIGHT-SEATSMAX.
CATCH SYSTEM-EXCEPTIONS CONVERSION_ERRORS = 1.
  MOVE 'abc' TO int.          " <- Error: CONVT_NO_NUMBER
  SELECT * FROM SFLIGHT
  INTO   SFLIGHT_WA
  WHERE  SEATSMAX = int.

    ...
  ENDSELECT.
ENDCATCH.
...

Notes

Using the class-based exception mechanism

We advise you to use only the class-based exception mechanism, not CATCH SYSTEM-EXCEPTIONS. You can use TRY...CATCH to catch any runtime error that can be caught using CATCH SYSTEM-EXCEPTIONS. New (that is, future) runtime errors will be available only as exception classes - you will not be able to catch them using CATCH SYSTEM-EXCEPTIONS. Since you cannot use CATCH SYSTEM-EXCEPTIONS and the class-based exception mechanism simultaneously in a procedural unit, we strongly advise you not to use CATCH SYSTEM-EXCEPTIONS for new coding.

Using runtime error identifiers and the exception group

We advise you to declare only exception groups in the CATCH statement. For a simple description of the error situations covered by a specific exception group, refer to Exception Groups.
You should only use the runtime error identifier if the error situation can be restricted easily. For more detailed information on when a runtime error can occur, refer to the Alphabetical Overview of All Runtime Errors.

Performance:

The CATCH...ENDCATCH statement pair requires 3-4 msn (standardized microseconds) runtime, provided a runtime error does not occur. If a runtime error needs to be caught, the program will take longer to run, depending on the type of error - from 3-4 seconds, to up to 20 seconds in some cases. In most cases, you should work on the assumption that runtime for error processing will be between 5-10 msn approximately.