The choice of the superclass influences the way that the syntax check and the runtime environment handle a given exception. Some of the standard exception classes are as follows:
- CX_STATIC_CHECK
If an exception class inherits from CX_STATIC_CHECK, you must either handle the relevant exception or propagate it using the RAISING addition. If the exception is neither handled nor propagated using the RAISING addition, the syntax check displays a warning. When you define a new global exception class, CX_STATIC_CHECK is defined as the superclass by default.
- CX_DYNAMIC_CHECK
For subclasses of CX_DYNAMIC_CHECK, the syntax check displays no warning if exceptions are neither handled nor propagated with the RAISING addition. If an exception is raised at runtime and you neither handle nor propagate it, the system ends the program with a runtime error.
- CX_NO_CHECK
For subclasses of CX_NO_CHECK, you cannot propagate the corresponding exceptions explicitly using the RAISING addition. If you do not handle these exceptions in the processing block where they occur, they are automatically propagated. If the calling block does not handle the exceptions, they are automatically propagated further on to the highest call hierarchy level. If the exceptions are not handled on the top level, a runtime error occurs at the point where they were raised. Some predefined exceptions with the prefix CX_SY_... for error situations in the runtime environment are subclasses of CX_NO_CHECK.

Exception Handling
Techniques to Handle an Exception Caught in a CATCH Statement
- Continue the program behind an ENDTRY statement after taking one of the following actions:
- Ignoring the exception (do nothing)
- Issuing a warning
- Writing to a protocol
- Correcting the situation
- Remove the cause of the error and start again from one of the following points:
- From the beginning of the corresponding TRY block using statement RETRY.
RETRY is new as of SAP NetWeaver 7.0 EhP 2.
- From where the exception occurred using statement RESUME.
RESUME is new as of SAP NetWeaver 7.0 EhP 2.
- Raise and propagate one of the following exceptions:
- The same exception object again using RAISE EXCEPTION <obj_ref>.
- A new exception using RAISE EXCEPTION TYPE <exc_class>.
The RETRY Statement
When you handle an exception in a CATCH block, use the RETRY statement to go back to the TRY statement of the respective TRY-ENDTRY structure, for example, if the cause for the exception was removed during the handling.
This technique is new with Release SAP NetWeaver 7.0 EhP 2.
In the example, the main program catches the exception that the constructor raised and propagated. After analyzing the exception object and correcting the error situation, the main program repeats the whole TRY block using the RETRY statement.
Caution: You must use RETRY with some caution. If you do not remove the cause of the exception properly, your program will go into an infinite loop.

Implementation of Resumable Exceptions
The handler of a given exception checks whether, at runtime a given exception was raised and propagated resumable or not. All exception objects provide public instance attribute IS_RESUMABLE, which is set to ’X’ or ’ ’ by the framework, depending on how the exception was raised and propagated. If you resume a non-resumable exception, you cause a runtime error (exception class CX_SY_ILLEGAL_HANDLER).

Use the RESUME statement to resume a program immediately after the statement that raised the exception in the source code.
You must satisfy the following prerequisites to use the RESUME statement:
- The exception must be caught with CATCH statement using the addition BEFORE UNWIND. This ensures that the context of the exception is kept alive for a possible RESUME. If the CATCH block exited without the RESUME statement, the system deletes the context of the exception after the CATCH block is exited.
- The exception must be raised with the RAISE RESUMABLE ... variant of the RAISE EXCEPTION statement. This prepares the raising processing lock for the RESUME.
-