CX_SY_ITAB_LINE_NOT_FOUND — CX_SY_ITAB_LINE_NOT_FOUND Dump Analysis

CX_SY_ITAB_LINE_NOT_FOUND is a class-based exception belonging to the CX_SY_ITAB_ERROR hierarchy. It is thrown specifically by the modern table expression syntax, for example wa = itab[ id = lv_id ] or a table expression nested inside VALUE# or COND#. Unlike classic READ TABLE, a table expression does not set sy-subrc when the line is missing. It raises this exception instead, and if no handler catches it, the runtime terminates with a short dump. The dump therefore almost never indicates a database or memory problem. It indicates that the internal table did not contain a row for the key or index requested at that exact point in the program, and the code was written assuming it always would.

If the cause is missing exception handling around a table expression, wrap the access in TRY/CATCH INTO cx_sy_itab_line_not_found and decide the fallback behaviour explicitly, or precede the access with a LINE_EXISTS check and branch accordingly. This is a code change and requires a transport through the normal development and testing path. If the cause is a data gap, for example a missing customizing entry or master record, the fix belongs in configuration or master data maintenance, not in the program, and may still need a transport if the fix is a customizing table change. If the cause is a conditional-population bug, the logic needs correcting so the table is guaranteed populated before the read, or the read is made conditional on the same flag as the population, followed by a regression test on the affected process. If the cause is a refactoring regression, restore the equivalent error handling that existed in the pre-refactor version and add a unit test covering the empty-table case so it cannot regress silently again.

The reflex fix is wrapping the table expression in TRY/CATCH with an empty or near-empty CATCH block just to stop the dump. This suppresses the short dump but leaves the workarea unfilled or partially filled, and the program continues executing with stale or initial field values. The failure resurfaces downstream, usually as GETWA_NOT_ASSIGNED, an incorrect posting, or a silently wrong result that is far harder to trace back to the original missing row than the original dump was.

Make TRY/CATCH or LINE_EXISTS mandatory around any table expression access in the coding standard, and enforce it through code review and ABAP Test Cockpit checks rather than relying on individual developer discipline. Add unit tests that exercise the empty-table and missing-key paths explicitly, not just the happy path, for any method that builds a lookup table from external data. Treat any refactor from classic READ TABLE to table expression syntax as requiring an explicit review of the old sy-subrc handling.

This is an ABAP development issue, not a Basis issue, since it is triggered by program logic rather than system resources. Functional input is needed to confirm whether the missing row reflects a genuine business scenario or a data gap that should not exist. The handover note should include the program, include, and line from the dump, the key values that failed to resolve, and the business document or transaction that triggered the run.

Closely related to ITAB_ILLEGAL_INDEX and TABLE_INVALID_INDEX, which cover index-based rather than key-based access failures on internal tables. Frequently appears alongside GETWA_NOT_ASSIGNED as a follow-on dump once an empty CATCH block has masked the original problem. Falls under the general UNCAUGHT_EXCEPTION and RAISE_EXCEPTION dump categories in terms of how ST22 classifies it, since it is fundamentally a class-based exception left unhandled.