MESSAGE_TYPE_X¶

Processing terminated by MESSAGE TYPE X.

The program called MESSAGE ... TYPE 'X' — an abort message — and nothing caught it. The entire work process is rolled back and ST22 is written.

Symptom¶

ST22 shows:

Runtime Errors         MESSAGE_TYPE_X
Short text             Processing terminated by MESSAGE TYPE X.

The "Variables in memory" section often contains the message class and number, giving you the actual business error that triggered the abort.

Cause¶

A MESSAGE statement with TYPE 'X' is ABAP's unconditional kill switch: it terminates the program immediately, rolls back the LUW, and writes a short dump. Developers sometimes use it as a "this should never happen" guard, but it also fires unexpectedly when:

A called function module or method uses MESSAGE ... TYPE 'X' internally.
A CHECK or ASSERT in older code maps to an X message.
A BAdI / user-exit forces an X message to block processing.
An unhandled RAISE in an older FM without proper exception handling defaults to X.

Common places to find the root message:

Short dump → "Variables in memory" → field SYMSGV1 / SYMSGV2

Or check SY-MSGID, SY-MSGNO, SY-MSGV1–SY-MSGV4 at the point of the abort.

Reproduce¶

MESSAGE e001(zmy_class) TYPE 'X'.   " unconditional dump

Fix¶

1 — Find the actual message¶

In ST22 expand "Active Calls / Events" to see the exact line that issued the X message, and "Variables in memory" to read the message text.

2 — Wrap the call in a TRY block (only works for exception-based X messages)¶

Some newer code raises CX_SY_NO_HANDLER when an X-type message is issued — you can catch it:

TRY.
    CALL FUNCTION 'SOME_FM'
      EXPORTING ...
      EXCEPTIONS
        OTHERS = 1.
  CATCH cx_sy_no_handler INTO DATA(lx).
    " log and continue gracefully
    MESSAGE lx->get_text( ) TYPE 'I'.
ENDTRY.

You cannot catch a raw MESSAGE ... TYPE 'X'

Classic X messages are not exceptions — they bypass TRY ... CATCH. The only fix is to find the source and change the message type, or ensure the code path that triggers it is never reached with invalid data.

3 — Change the message type at the source¶

If you own the code, replace TYPE 'X' with TYPE 'E' (error) or raise a proper class-based exception so callers can handle it:

" Before
MESSAGE e001(zmy_class) TYPE 'X'.

" After — raises catchable exception
RAISE EXCEPTION TYPE zcx_my_exception
  MESSAGE e001(zmy_class).

Background jobs¶

X messages in background jobs produce a dump entry in SM37 (job log) and ST22. The job is cancelled and no COMMIT is written. Always test new jobs in dialog mode first.

Prevention¶

Never use TYPE 'X' in reusable code (FMs, classes, BAdIs) — raise a proper exception instead.
For guards/assertions, use ASSERT (raises ASSERTION_FAILED) or a catchable exception.
When calling third-party or standard FMs, inspect ST22 entries after testing to discover hidden X paths.