RAISE_EXCEPTION — RAISE_EXCEPTION Dump: Uncaught Classic Exception

RAISE_EXCEPTION belongs to the pre-object-oriented exception mechanism, the one used with FUNCTION ... EXCEPTIONS lists and RAISE <name> inside FORM routines or function modules. Under this model the caller must explicitly name every exception it wants to trap, either individually or with the catch-all OTHERS, on the CALL FUNCTION or PERFORM statement. When the routine executes RAISE <name> and that name was not in the caller's list, and OTHERS was not specified either, the kernel has nowhere to route control and terminates the program. This is not the same mechanism as TRY/CATCH with class-based exceptions, which produces UNCAUGHT_EXCEPTION instead. RAISE_EXCEPTION almost always indicates a mismatch between what a called routine's interface can raise and what the calling code was written to expect, usually because one side changed after the other was written.

If the cause is a missing named exception in a custom program's call statement, add the exception name to the EXCEPTIONS addition and write explicit handling for it, then transport the change; this is a mandatory change request since it touches program logic. If the cause is a standard SAP function module whose interface changed via support package, check whether the correction is already delivered as a modification to the call itself; if the call sits in custom code, the fix still has to be made locally and transported. If the cause is an RFC or BAPI version mismatch between systems, coordinate the interface versions or add OTHERS with logged, non-silent handling as an interim measure while the version alignment is scheduled. If the cause is a stale PERFORM after a subroutine refactor, update every call site found through a where-used list, not just the one that dumped, since others are likely to fail the same way under different data. None of these should be closed with OTHERS alone unless a genuine handling branch is written behind it.

The reflex fix is adding EXCEPTIONS OTHERS = 9 (or similar) to the call purely to stop the dump, with no code afterward that inspects SY-SUBRC or reacts to it. This does stop the termination, but it also silently swallows whatever business condition triggered the exception in the first place, such as a locked master record, insufficient stock, or a failed authorization check inside the called routine. The program then falls through to the next statement as if nothing happened, often producing a worse failure downstream: a posting that should not have happened, a document created against invalid data, or a batch job that reports success while having skipped real work.

Enforce a code review rule that any CALL FUNCTION or PERFORM using the classic EXCEPTIONS mechanism must list every exception in the called routine's current interface, with OTHERS present only as a last resort and always followed by explicit error handling, never left empty. When changing the exception interface of a shared function module or subroutine, run a where-used analysis before release and update every caller in the same transport. For RFC-based BAPI calls, regenerate or re-check the local proxy interface whenever the remote system's function module signature changes.

This is an ABAP development issue, not Basis, since it is resolved by correcting the exception list on a call statement. If the underlying routine is standard SAP and its interface changed through an upgrade, functional involvement is needed to confirm the business meaning of the new exception before deciding how to handle it. The handover note should include the function module or subroutine name, the exception name, the exact caller program and line, and the business scenario that triggered the RAISE.

UNCAUGHT_EXCEPTION is the object-oriented counterpart, raised when a class-based exception thrown with RAISE EXCEPTION TYPE cx_... is not caught anywhere in the call stack; the two are often confused because both stem from a RAISE statement. CALL_FUNCTION_PARM_MISSING and CALL_FUNCTION_REMOTE_ERROR arise from adjacent problems in the same call statements, parameter mismatches and remote-side failures rather than exception handling gaps. ASSERTION_FAILED and MESSAGE_TYPE_X are other abrupt-termination patterns worth checking when a program's error handling strategy is being reviewed end to end.