UNCAUGHT_EXCEPTION — UNCAUGHT_EXCEPTION short dump

ABAP has two exception mechanisms: the old classic RAISE, which produces the RAISE_EXCEPTION dump, and class-based exceptions built on CX_ROOT and its subclasses, raised with RAISE EXCEPTION TYPE or RAISE EXCEPTION NEW. UNCAUGHT_EXCEPTION fires when a class-based exception propagates through every calling method and program without being caught. The runtime does not know what to do with an unhandled object reference exception, so it terminates the session and writes the dump. The dump identifies the exception class, the method or form that raised it, and the point in the call stack where propagation stopped because nothing above it declared a matching CATCH. This is a design gap, not a syntax error: the code compiled and ran, but the exception contract between caller and callee was not honoured somewhere along the chain.

If a custom method call lacks a CATCH, add TRY/CATCH INTO a reference variable of the specific exception class or its documented superclass, then decide the handling: raise an application message, log via the application log, or re-raise a business-meaningful exception to the caller. This requires a code change and a transport. If the exception originates in standard SAP code because of bad customizing or missing master data (for example a currency, unit, or number range configuration gap that a standard method turns into an exception), fix the configuration or data, not the code; no transport of ABAP is needed, though a change to customizing tables still needs its own change process. If a BAdI or user-exit implementation raises an exception the framework cannot catch, correct the implementation to either handle the condition internally or raise only what the interface signature permits; this is a transportable code fix. If the cause is a signature change in standard code after an upgrade, adjust the custom caller's CATCH clause to cover the new exception class; this is mandatory post-upgrade remediation, not optional cleanup. If the raising logic sits inside standard, unmodified SAP code with no configuration explanation, this is the case to open an incident with SAP rather than attempt a local workaround.

The reflex is to wrap the failing call in TRY. CATCH INTO cx_root. ENDTRY. with an empty or near-empty catch block, or to catch the specific exception and do nothing with it. This stops the dump immediately, which is exactly why it feels like a fix, but it discards the exception's payload and the business condition it was reporting. The program continues past a state it was never designed to continue past, often producing incomplete postings, skipped records, or silently wrong output that surfaces days later as a reconciliation break, by which point the original stack trace is gone and the investigation starts from zero.

Run static code checks, such as the ABAP Test Cockpit or code inspector variants, that flag method calls with a declared RAISING clause and no corresponding CATCH in the caller, and flag any CATCH INTO cx_root that does not re-raise or log. Enforce a project standard that custom programs have one central exception-handling layer near the top of the call stack that logs to the application log with enough context to identify the business object involved, rather than scattering ad hoc CATCH blocks. Re-run affected custom code through a syntax and unit test check after any upgrade that changes standard method signatures.

ABAP development owns this in the large majority of cases, since the fix is almost always a missing or incorrect CATCH block or an exception-raising custom enhancement. Functional consultants get involved when the exception is standard SAP code reacting to a configuration or master data gap. Basis is rarely involved unless the dump occurred inside an RFC connection or background job infrastructure. The handover note should include the exception class, the exact raising line from the call stack, the business transaction and key that triggered it, and whether it reproduces on demand.

RAISE_EXCEPTION is the classic, non-class-based sibling of this dump and shares the same root cause pattern of an unhandled error condition. MESSAGE_TYPE_X is the older style of abnormal termination raised via MESSAGE ... TYPE 'X' and often gets converted to a class-based exception in newer code. ASSERTION_FAILED comes from a failed ASSERT statement rather than an explicit RAISE, but is diagnosed the same way through the call stack. CALL_FUNCTION_REMOTE_ERROR appears when the uncaught exception originates on the far side of an RFC call. MOVE_CAST_ERROR is frequently the underlying CX_SY_ class seen inside an UNCAUGHT_EXCEPTION dump when a downcast fails.