Skip to content

RAISE_EXCEPTION

A classic (non-class-based) exception was raised and no caller handled it.

An older-style RAISE statement or an unhandled CALL FUNCTION ... EXCEPTIONS exception propagated all the way to the top of the call stack without being caught.

Symptom

ST22 shows:

Runtime Errors         RAISE_EXCEPTION
Exception              (classic exception, not class-based)
Short text             Exception condition "EXCEPTION_NAME" triggered.

The dump names the exception and the function module or form routine that raised it. There is no catchable CX_* class — classic exceptions are not objects.

Cause

Classic ABAP exceptions predate class-based exceptions. They work through the EXCEPTIONS addition on CALL FUNCTION and PERFORM:

  • The FM or form maps exception names to SY-SUBRC values when the caller lists them.
  • If the caller omits the EXCEPTIONS block entirely, or lists some exceptions but omits OTHERS, any unlisted exception propagates up the stack as a dump.
  • A bare RAISE my_exception inside a subroutine with no EXCEPTIONS declaration in its signature immediately causes the dump.

Missing OTHERS is the most common culprit

Adding EXCEPTIONS but omitting OTHERS = N is worse than omitting EXCEPTIONS altogether in some respects — it silently drops listed exceptions into SY-SUBRC but lets any unknown exception dump the program.

Reproduce

Function module Z_MY_FM raises exception MY_ERROR internally:

" Inside Z_MY_FM:
RAISE my_error.

Caller provides no EXCEPTIONS addition:

" Caller — dumps with RAISE_EXCEPTION when FM raises MY_ERROR
CALL FUNCTION 'Z_MY_FM'
  EXPORTING
    iv_input = lv_value.

Caller lists exceptions but omits OTHERS — unknown exception still dumps:

CALL FUNCTION 'Z_MY_FM'
  EXPORTING
    iv_input = lv_value
  EXCEPTIONS
    known_error = 1.      " OTHERS missing — any other exception dumps

Fix

CALL FUNCTION 'Z_MY_FM'
  EXPORTING
    iv_input = lv_value
  EXCEPTIONS
    my_error = 1
    OTHERS   = 2.

CASE sy-subrc.
  WHEN 0.
    " success
  WHEN 1.
    MESSAGE 'MY_ERROR raised by FM' TYPE 'E'.
  WHEN OTHERS.
    MESSAGE 'Unexpected error in Z_MY_FM' TYPE 'E'.
ENDCASE.

FORM my_routine
  EXCEPTIONS
    my_error.

  " ... some logic ...
  RAISE my_error.
ENDFORM.

" Caller:
PERFORM my_routine
  EXCEPTIONS
    my_error = 1
    OTHERS   = 2.

IF sy-subrc <> 0.
  " handle error
ENDIF.

" New-style FM or method — raises a catchable class-based exception
RAISE EXCEPTION TYPE zcx_my_exception
  MESSAGE e001(zmy_class).

" Caller:
TRY.
    CALL FUNCTION 'Z_MY_NEW_FM'
      EXPORTING iv_input = lv_value.
  CATCH zcx_my_exception INTO DATA(lx).
    MESSAGE lx->get_text( ) TYPE 'I'.
ENDTRY.

SY-SUBRC after every CALL FUNCTION

Make it a habit: every CALL FUNCTION must be followed by a SY-SUBRC check, even when you expect success. Silent SY-SUBRC <> 0 values that go unchecked accumulate into hard-to-trace bugs.

Prevention

  • Add EXCEPTIONS ... OTHERS = N to every CALL FUNCTION — no exceptions (pun intended).
  • In new code, use class-based exceptions (RAISE EXCEPTION TYPE, TRY ... CATCH) — they are catchable at any level and carry a text automatically.
  • Run the Extended Program Check (SLIN) — it flags CALL FUNCTION calls that are missing EXCEPTIONS or OTHERS.
  • Audit legacy code with transaction SCOV or code inspector to find unguarded FM calls.

See also

  • MESSAGE_TYPE_X — related dump when an error escalates to an X message
  • Transaction ST22 — ABAP runtime error analysis
  • Transaction SLIN — extended program check

Comments