Class-Based Exceptions in ABAP: TRY, CATCH, CLEANUP and RAISING

Modern ABAP exception handling replaces many ad hoc SY-SUBRC/message patterns with typed exception objects. An exception class can hold attributes, previous exceptions, message interfaces, and context. Methods declare checked exceptions in RAISING where required. TRY encloses protected code, CATCH handles compatible exception types from specific to general, and CLEANUP runs when an exception leaves the current TRY without being caught there. CLEANUP therefore has precise propagation semantics and should not be treated as Java-style finally code that always runs.

Use class-based exceptions for reusable classes, APIs, complex validation, infrastructure wrappers, and any call chain where the caller needs to distinguish error categories or preserve context. Use RETURN/BAPIRET2 when the called SAP API defines that contract; a wrapper may translate blocking return messages into a domain exception for its own callers. Avoid exceptions for ordinary branching such as 'no rows found' when absence is a valid business outcome.

Exceptions are part of OO ABAP, RAP implementations, HTTP clients, persistence wrappers, testable services, and modern released APIs. They can chain a previous exception so low-level context is preserved while callers see a higher-level domain error. Application logging can record the exception while the caller decides whether to retry, roll back, or convert it into a message. Exception design is therefore both a technical and semantic API decision.

A service reads an external API, converts the response, and saves a business object. The HTTP client can raise communication exceptions; the parser can raise format exceptions; the business API can return application errors. A wrapper catches the low-level technical exceptions, adds operation/context, and raises a domain-specific checked exception with PREVIOUS. The top-level job catches that domain exception, writes it to BAL, and ends gracefully without losing the original cause.

Class-based exceptions are standard modern ABAP in S/4HANA and ABAP Cloud. New released APIs frequently use exception classes, while older BAPIs/function modules may still expose classic exceptions or RETURN tables. Modernization often means building a clean typed exception contract around those legacy interfaces rather than propagating every old message format through the application.

ABAP API owners define exception semantics; callers decide recovery policy. Architects should ensure exceptions do not leak sensitive payloads into logs. Operations teams benefit when exceptions preserve enough context to correlate with job, RFC, HTTP, or application-log evidence.

Object-oriented ABAP provides the class/interface context. BAL Application Log is the normal place for durable operational diagnostics. BAPI transaction topics explain when RETURN messages should be translated versus handled directly.

Production verification: Capture the public interface or contract, concrete implementation class, caller, exception type and previous exception, and any dynamic type or component metadata involved. Unit tests should cover both the happy path and contract failures so a refactor cannot silently change exception or dynamic-mapping behavior.

Operational readiness: For production readiness of Class-Based Exceptions in ABAP: TRY, CATCH, CLEANUP and RAISING, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.