An exception can be defined as an intermediary situation between program run and execution, after which it is irrelevant to continue the program any further. In this example, we will see how exceptions and exception handling are realized using classes.
An exception is represented by an exception object, which is an instance of an exception class. Exception classes are predefined in ABAP. However, a user can also define an exception class.
An exception is raised using the RAISE EXCEPTION statement, which instantiates the exception class. Attributes of the exception contain the error information. Every exception that is raised is handled by the exception handling block that analyzes its attributes.
EXCEPTION CLASSES: THE INHERITENCE HIERARCHY
Exception classes are already predefined in the system. All exception classes are derived from CX_ROOT which implements the interface IF_MESSAGE. It contains the get_text method, which returns an exception text in the form of a string. CX_ROOT cannot be inherited directly. Therefore, any new exception class that is defined is inherited from any of its subclasses, such as CX_NO_CHECK, CX_DYNAMIC_CHECK, and CX_STATIC_CHECK. The method – get_source_position – returns certain details, such as the name of the main program, the name of the include program, and the line number in the source code where the exception occurred.
STRUCTURE OF TRY-ENDTRY BLOCK
An exception that is raised is handled using a CATCH statement in the TRY-ENDTRY block. The try block contains statements for which exception needs to be handled. Exception handlers associated with different exceptions are defined in the CATCH block. When an exception is raised, the system automatically searches for an appropriate CATCH statement in the TRY-ENDTRY block. If a handler is not available in the TRY-ENDTRY block, then the CLEANUP block is executed.
EXAMPLE SYNTAX FOR HANDLING PREDEFINED EXCEPTION
Let us understand exception handling with the help of an example. The variable gv_result in the TRY block holds a particular value based on the operation defined. The predefined exception –CX_SY_ARITHMETIC_OVERFLOW – should be raised if the value of the variable gv_result exceeds its permissible type limit (int).The INTO addition in CATCH statement is used to specify a reference variable (gx_exc) of type cx_root to hold the attributes of the exception object. The string variable – gv_text – is used to display the exception information using the get_text () method.
CLASS-BASED EXCEPTION IN DEBUGING MODE
In debugging mode, if an exception is caught in the CATCH block, the user is intimated through a success message and that particular CATCH statement is displayed. As shown here, the user can make use of pushbuttons to see the corresponding exception object and the source code where the exception originated.
CREATING GLOBAL EXCEPTION CLASSES
User-defined exception classes can be created using the class builder or Object Navigator. Select option ‘Create’ from the right-click context menu options, as shown here. Specify a class name with a class type. Follow naming convention while specifying the name for a user-defined class. As of SAP NW AS 6.40, message classes can be used to display information.
DEFINE VARIABLE EXCEPTION TEXTS
User-defined attributes can be used to provide information for exceptions.
As of SAP NW AS 6.40, you can use message classes to display information. User can provide the text for exception using the ‘Texts’ tab, as shown.
VARIANTS OF STATEMENTS RAISE EXCEPTIONS ........
You can create and raise exceptions with any of these syntaxes:
RAISE EXCEPTION TYPE <exception_class> [EXPORTING ...] statement creates an instance of the exception class and raises the exception in a single step. Attributes to the exception can be passed through a constructor using the EXPORTING addition. RAISE EXCEPTION <object_ref> statement can be used if an exception object is already defined. In this case, an instance of the exception class is first created, which is then followed by the RAISE statement.SETTING THE EXCEPTION TEXT
Every exception class has some text associated with it, which is usually the name of the exception class. Whenever the exception is raised, the text is displayed. If the user wishes to display text other than the one available by default, then instead of TEXTID, the corresponding constant (cx_invalid_planetype2) is passed as an actual parameter to the constructor. The get_text( ) method is used to get the new defined text.
PROPAGATING CLASS-BASED EXCEPTIONS
The RAISING addition is specified in method definition to raise an exception from a method. In this example, the RAISING addition is used in the constructor method. The RAISE EXCEPTION statement is specified in the constructor method definition. The exception is then handled in the calling program.
PROPAGATING EXCEPTION OVER SEVERAL HIERARCHY-LEVEL
It is not mandatory that a class-based exception is handled by the calling method in which it is propagated. As shown in this example, the constructor propagates an exception cx_exc which is raised by the method get_tech_attr. When an exception is raised, the program flow jumps directly to the CATCH block in the main program.
INTEGRATION OF STANDARD EXCEPTIONS IN THE RUNTIME SYSTEM
The way an exception is handled is determined by the superclass it is inherited from. In case of
CX_STATIC_CHECK, exception must be handled using the RAISING addition. Otherwise, a warning message is displayed. CX_DYNAMIC_CHECK, no warning message is displayed from syntax check. However, if they are not handled during program execution, runtime error occurs. CX_NO_CHECK, exception cannot be propagated explicitly using the RAISING addition.HANDLING EXCEPTIONS: TRY-ENDTRY BLOCK
When the word RETRY is encountered in the source code, program control jumps back to the TRY statement of the TRY–ENDTRY block.
RETRY STATEMENT
As shown in this example, after an exception is raised, the error situation is analyzed. When the system encounters the RETRY statement, program control jumps to the TRY statement. Subsequently, the entire code is executed again.
RESUME EXECUTION AFTER A RESUMABLE EXCEPTIONS
In order to resume normal processing after an exception is raised, the exception is first handled using the CATCH BEFORE UNWIND statement. Subsequently, it is checked for its resumable property. If the property set is true, then the RESUME statement is executed. However, raising and propagation of the exception are handled by get_tech_attr method.
RE-RAISING AN EXISTING EXCEPTION OBJECT
When the CATCH statement is encountered, exception handling is done by the constructor. The CALL METHOD statement in the constructor calls the method, get_tech_attr, which contains the RAISE EXCEPTION statement as shown here. The exception object of the constructor is passed to the reference variable of the CATCH statement in the main program. The exception object is called again in the main program.
MAPPING EXCEPTION TO EACH OTHER
An exception can raise another exception. As seen in this example, the exception is handled in the constructor using the get_tech_attr method, which raises another exception. Both these exception objects are chained together using the public instance attribute – previous – of the exception classes.
No comments:
Post a Comment