OOP ABAP Part 4: Class-Based Exceptions

📌 KEY POINTS
✅ Class-based exceptions are objects: RAISE EXCEPTION TYPE zcx_… and handle them with TRY … CATCH … ENDTRY.
✅ Three kinds: CX_STATIC_CHECK (must be declared/handled), CX_DYNAMIC_CHECK (runtime-checked), CX_NO_CHECK (system-like, never declared).
✅ Custom exception classes (ZCX_…) can carry T100 message texts and attributes.
⚠️ Classic EXCEPTIONS (sy-subrc) and class-based exceptions cannot be mixed in one method signature.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Methods in Parts 1–3 wrote errors to the list. Reusable code must instead signal errors to the caller.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CLASSIC ERROR HANDLING (FOR COMPARISON)
Function modules declare EXCEPTIONS not_found = 1 and the caller checks sy-subrc after CALL FUNCTION. It still exists in every system (BAPIs use a RETURN table instead). It is easy to forget the sy-subrc check, and no details travel with the error.

━━━━━━━━━━━━━━━━━━━━
▶ 2. TRY / CATCH / CLEANUP

TRY.

lo_service->book( … ).
CATCH zcx_flight_error INTO lx_error.
MESSAGE lx_error TYPE 'I' DISPLAY LIKE 'E'.

CLEANUP.

" runs when the exception leaves this TRY block unhandled

ENDTRY.

• CATCH blocks are checked in order — catch specific classes before general ones (CX_ROOT last).
• INTO lx_error gives the exception object: get_text( ), previous, custom attributes.

━━━━━━━━━━━━━━━━━━━━
▶ 3. THE THREE CATEGORIES

• CX_STATIC_CHECK — the compiler checks: a method must declare it with RAISING or handle it. Use for expected business errors (flight full, customer blocked).
• CX_DYNAMIC_CHECK — declaration only checked at runtime; for errors callers can usually prevent (e.g. CX_SY_ZERODIVIDE).
• CX_NO_CHECK — may occur anywhere, never declared (e.g. resource shortages).

━━━━━━━━━━━━━━━━━━━━
▶ 4. CUSTOM EXCEPTION CLASS
SE24: create ZCX_FLIGHT_ERROR, superclass CX_STATIC_CHECK, tick "With Message Class". Add interface IF_T100_MESSAGE texts mapping to message class ZFLIGHT (e.g. FLIGHT_FULL = message 001 with &1 &2). Attributes (MV_CARRID, MV_CONNID) fill the placeholders.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RAISING
RAISE EXCEPTION TYPE zcx_flight_error EXPORTING textid = zcx_flight_error=>flight_full mv_carrid = iv_carrid mv_connid = iv_connid.
💡 Modern (7.50+): RAISE EXCEPTION NEW zcx_flight_error( … ) and MESSAGE e001(zflight) WITH … in RAISE EXCEPTION … MESSAGE.

━━━━━━━━━━━━━━━━━━━━
▶ 6. CHAINING
Catch a technical exception and raise a business one with previous = lx_technical to keep the root cause.

━━━━━━━━━━━━━━━━━━━━
▶ 7. DO NOT

• Catch CX_ROOT everywhere and ignore it.
• Mix MESSAGE type E inside reusable methods — raise an exception instead.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Create ZCX_FLIGHT_ERROR as in the code comments.
2. Run the report: book a full flight, see the message text from ZFLIGHT.
3. Add a CLEANUP block and observe when it runs.

✅ CHECKPOINT: your methods signal errors with exceptions, and callers handle them explicitly.

A reusable pricing class issued MESSAGE type E when a condition was missing. When the class was later called from a background interface and an OData service, the MESSAGE caused job terminations and unreadable HTTP errors.
The team replaced it with ZCX_PRICING_ERROR (CX_STATIC_CHECK with T100 texts). The report shows the text as a message, the OData layer maps it to a proper error response, and the background job logs it in the application log and continues with the next document.

• MESSAGE type E inside reusable methods.
• Catching CX_ROOT and doing nothing.
• CATCH of a superclass before a subclass (subclass block never reached).
• Not declaring static-check exceptions with RAISING.
• Losing the root cause instead of using previous.

• Use CX_STATIC_CHECK subclasses for expected business errors.
• Put texts in a message class via IF_T100_MESSAGE.
• Catch specific exceptions first; handle at the layer that can react.
• Chain technical causes with previous.
• Map exceptions to the channel: message in UI, BAPIRET2 in RFC, error response in OData.

Questions: "Static vs dynamic vs no-check exceptions?", "Classic EXCEPTIONS vs class-based?", "What does CLEANUP do?"
Strong answer: class-based exceptions are objects raised with RAISE EXCEPTION and caught with TRY/CATCH; CX_STATIC_CHECK must be declared or handled (compile-time check), CX_DYNAMIC_CHECK checked at runtime, CX_NO_CHECK never declared; custom classes carry T100 texts and attributes; CLEANUP runs when the exception propagates out; classic EXCEPTIONS use sy-subrc and cannot be mixed in one signature.