ASSERTION_FAILED — ASSERTION_FAILED short dump

An ASSERT statement is a developer's explicit sanity check: 'this condition must hold here, and if it does not, stop immediately rather than continue with corrupted state.' ASSERTION_FAILED fires the moment that check evaluates to false. Unlike most dumps, this is not the kernel or database complaining, it is application logic refusing to proceed because an internal assumption broke. The technical exception is CX_SY_ASSERTION_FAILED, a resumable but usually uncaught exception. The dump text is frequently unhelpful on its own, sometimes just the line number and program, because the developer who wrote the ASSERT rarely supplied a descriptive message. This makes the call stack, not the dump text, the primary diagnostic asset. It can occur in SAP standard programs, in enhancements, or in custom Z code, and the fix path differs sharply depending on which of those three it is.

If the stack shows only standard SAP objects and no custom code touched the data beforehand, treat it as a potential standard defect: check the support package level against the fix and apply the correction through the normal transport landscape, which requires a change request. If a Z program or enhancement appears in the stack feeding bad data into standard logic, the fix is in the custom layer: correct the calling code so it never sends the invalid combination, and transport that change. If the ASSERT itself sits in custom code and is protecting against a condition that can legitimately happen in production, replace it with proper exception handling or a message, since removing the ASSERT without adding real validation just moves the failure downstream. If the root cause is master data or customizing, correct the data through the functional transaction, no code change or transport needed, but confirm with the functional owner why the inconsistent data was allowed to exist in the first place. Any code-level fix, standard or custom, needs a transport and should go through normal testing before production, even under pressure to close an incident quickly.

The reflex is to wrap the offending call in a TRY/CATCH for CX_ROOT or CX_SY_ASSERTION_FAILED and swallow it, or to comment out the ASSERT in a modified standard include. Both make the symptom disappear without touching the underlying data or logic problem the ASSERT was built to catch. The program then continues with the exact inconsistent state the developer decided was unsafe to proceed on, and the failure resurfaces later as silently wrong output, a stuck document, or a harder-to-trace dump further downstream where there is no assertion left to catch it.

In custom development, restrict ASSERT to conditions that are genuinely impossible under correct logic, never to conditions that depend on production data quality or configuration completeness; those belong in explicit validation with a caught exception or a user message. Review any enhancement or BAdI that modifies data after a standard validation step has already run against it. Keep support packages and kernel patches reasonably current so known assertion defects in standard code are already closed rather than rediscovered in production.

Ownership depends entirely on where the ASSERT sits in the stack: standard-code-only failures with no custom involvement go to Basis for patch-level checks and ABAP for note research; custom code or enhancement failures go to the ABAP developer who owns that object; data-driven failures go to the functional consultant who owns the master data or customizing area. The handover note should include the exact program, include, and line, the full call stack, and the field values active at failure.

ASSERTION_FAILED sits alongside RAISE_EXCEPTION and UNCAUGHT_EXCEPTION as a family of dumps triggered by explicit ABAP statements rather than by the kernel or database layer, and MESSAGE_TYPE_X as another deliberate hard-stop pattern developers use. It can appear inside almost any transaction since ASSERT statements are scattered throughout standard code, so the relevant transaction is whichever one was running at the time, not a fixed one. ST22 and SM21 are the primary tools for diagnosis.