What does it do? This statement interrupts execution of the current statement block and raises a class-based exception>. It can be used at any point in a processing block>. The statement interrupts the program flow and searches for a handler> as described in System Response After a Class-Based Exception>. Depending on the definition of the handler, the context of the exception is closed before or after the handler is executed, where some cleanup tasks> may be performed. During handling, processing can only be resumed again after the statement RAISE EXCEPTION>, without closing the context, if the addition RESUMABLE> is specified.
If the addition TYPE> is specified, an exception of exception class cx_class> is raised and, if necessary, an exception object is created. Every exception class cx_class> visible at this point can be specified after TYPE>.
The addition EXPORTING> can be used to assign actual parameters to the input parameters of the instance constructor.
The addition message>> can be used to link the exception object to a message >.
If oref> is specified, no new exception object is created when the exception is raised. For oref>, an object reference variable must be specified that points to an existing exception object. The static type of oref> must be an exception class, that is, a subclass of CX_ROOT> or the class itself. oref> is a general expression position>. In the existing exception object, the internal attributes that describe the position of the exception and that can be read using the method GET_SOURCE_POSITION> are converted to the position of the statement RAISE>. BEGIN_SECTION VERSION 5 OUT The statement RAISE EXCEPTION> must not be used in a method or function module in whose interface non-class-based> exceptions are declared. Furthermore, it does not allow simultaneous use of the statement CATCH SYSTEM-EXCEPTIONS>> for the obsolete handling of catchable runtime errors> or RAISE>> or MESSAGE RAISING>> for raising non-class-based exceptions in function modules and methods in the current processing block. END_SECTION VERSION 5 OUT
Latest notes:
If the addition TYPE> is used exception objects are only created if they are required for performance reasons, that is:
If a suitable CATCH> block or CLEANUP> block is specified in a wrapper TRY>> control structure with the addition INTO>.
If the exception is not caught and a runtime error> occurs. In principle, however, an exception can be regarded as an instance of an exception object being generated. A difference in behavior can occur only if a non-handled exception of the instance constructor replaces the original exception when the object is generated. However, this situation should never occur.
If oref> is specified, either an exception object instantiated using NEW>> or CREATE OBJECT>> can be used, or an exception that was previously caught during exception handling can be raised again.
If a caught exception is raised again, note that the exception object does not remain unchanged because the information about the position of the exception is changed. If the original information is to be propagated to an external handler, a new exception of the same class can be raised, passing the original exception object to the PREVIOUS> parameter of its constructor. It may also be enough to propagate the original exception implicitly, and not raise it again using RAISE >. The associated original exception object can then be evaluated in the CLEANUP>> block, if required
The exception class after TYPE> can be specified only statically. To raise an exception dynamically, the dynamic variant of CREATE OBJECT>> can be used to create an exception object and specify it using oref>.
If a procedure> is exited by raising an exception, the content of the formal parameter for which the pass by value> is defined is not assigned to the respective actual parameters.
The addition THROW>> in a conditional expression> makes it possible to raise a class-based exception in an operand position. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Raising of an exception cx_demo> in a method. ABEXA 00507 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 Raising of a caught exception of the class cx_demo> again using the exception object. ABEXA 00508 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 Raising of an exception using a dynamically created exception object. ABEXA 00509 ABAP_EXAMPLE_END
What does it do? The addition RESUMABLE> raises an exception as a resumable exception>. When an exception of this type is handled in a CATCH> > block, the statement RESUME>> can be used to return to the point directly after the raising statement, as long as the context of the exception was not deleted before the exception was handled.
Latest notes:
If the statement RESUMABLE> is used to raise an exception as a resumable exception>, the handler has to determine whether processing is resumed after RAISE EXCEPTION >, or whether processing of the current context is terminated completely. Both alternatives can occur when an exception is raised. It is important to ensure that CLEANUP>> blocks are only executed when the context is deleted.
When exceptions of the types CX_STATIC_CHECK> and CX_DYNAMIC_CHECK> are propagated, which are raised as resumable, they can become non-resumable if the addition RESUMABLE> is not specified in each interface involved for the addition RAISING> to declare the exception.
When exceptions of type CX_NO_CHECK> are propagated, the resumability is always retained. However, exceptions of type CX_NO_CHECK> should only be raised as resumable with caution, and it must be ensured that a procedure always has the required behavior. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 Raising of a resumable exception cx_demo> using the addition RESUMABLE> in a method.