CX_STATC_CHECK

CX_DYNAMC_CHECK

CX_SY_ARTHMETC_ERROR

CX_SY_ZERODVDE

CX_SY_ARTHMETC_OVERFLOW

CX_SY_ARG_OUT_OF_DOMAN

CX_SY_PRECSON_LOSS

CX_SY_ASSGN_ERROR

CX_SY_ASSGN_CAST_ERROR

CX_SY_ASSGN_CAST_LLEGAL_CAST

CX_SY_ASSGN_CAST_UNKNOWN_TYPE

CX_SY_ASSGN_OUT_OF_RANGE

CX_SY_CODEPAGE_CONVERTER_NT

CX_SY_CONVERSON_ERROR

CX_SY_CONVERSON_CODEPAGE

CX_SY_CONVERSON_DATA_LOSS

CX_SY_CONVERSON_NO_BOOLEAN

CX_SY_CONVERSON_NO_DATE_TME

CX_SY_CONVERSON_NO_NUMBER

CX_SY_CONVERSON_NO_RAW

CX_SY_CONVERSON_NO_UUD

CX_SY_CONVERSON_OVERFLOW

CX_SY_CONVERSON_ROUNDNG

CX_SY_CONVERSON_UNKNOWN_LANGU

CX_SY_CREATE_ERROR

CX_SY_CREATE_OBJECT_ERROR

CX_SY_CREATE_DATA_ERROR

CX_SY_DATA_ACCESS_ERROR

CX_SY_RANGE_OUT_OF_BOUNDS

CX_SY_TAB_RANGE_OUT_OF_BOUNDS

CX_SY_OFFSET_NOT_ALLOWED

CX_SY_DYN_CALL_ERROR

CX_SY_DYN_CALL_LLEGAL_CLASS

CX_SY_DYN_CALL_LLEGAL_FORM

CX_SY_DYN_CALL_LLEGAL_FUNC

CX_SY_DYN_CALL_LLEGAL_METHOD

CX_SY_DYN_CALL_PARAMETER_ERROR

CX_SY_DYN_CALL_EXCP_NOT_FOUND

CX_SY_DYN_CALL_LLEGAL_TYPE

CX_SY_DYN_CALL_PARAM_MSSNG

CX_SY_DYN_CALL_PARAM_NOT_FOUND

CX_SY_EXPORT_NO_SHARED_MEMORY

CX_SY_FLE_ACCESS_ERROR

CX_SY_FLE_AUTHORTY

CX_SY_FLE_CLOSE

CX_SY_FLE_O

CX_SY_FLE_OPEN

CX_SY_FLE_OPEN_MODE

CX_SY_FLE_POSTON

CX_SY_FLE_TRUNCATE

CX_SY_FND_NFNTE_LOOP

CX_SY_GEN_SOURCE_TOO_WDE

CX_SY_MPORT_MSMATCH_ERROR

CX_SY_MPORT_FORMAT_ERROR

CX_SY_TAB_ERROR

CX_SY_TAB_DUPLCATE_KEY

CX_SY_MATCHER

CX_SY_REGEX_TOO_COMPLEX

CX_SY_NVALD_REGEX_FORMAT

CX_SY_MOVE_CAST_ERROR

CX_SY_PROGRAM_NOT_FOUND

CX_SY_PROVDE_EXCEPTON

CX_SY_PROVDE_NTERVAL_OVERLAP

CX_SY_PROVDE_TABLE_NOT_SORTED

CX_SY_READ_SRC_LNE_TOO_LONG

CX_SY_REF_S_NTAL 

CX_SY_REGEX

CX_SY_NVALD_REGEX

CX_SY_REPLACE_NFNTE_LOOP

CX_SY_SCAN_SOURCE_TOO_WDE

CX_SY_SQL_ERROR

CX_SY_OPEN_SQL_ERROR

CX_SY_OPEN_SQL_DB

CX_SY_DYNAMC_OSQL_ERROR

CX_SY_DYNAMC_OSQL_SEMANTCS

CX_SY_DYNAMC_OSQL_SYNTAX

CX_SY_NATVE_SQL_ERROR

CX_SY_UNKNOWN_CURRENCY

CX_SY_WRTE_NVALD_STYLE

CX_SY_WRTE_SRC_LNE_TOO_LONG

CX_TRANSFORMATON_ERROR

CX_ST_ERROR

CX_ST_CALL_ERROR

CX_ST_CALL_METHOD_ERROR

CX_ST_CONSTRANT_ERROR

CX_ST_CONDTON

CX_ST_DESERALZATON_ERROR

CX_ST_FORMAT_ERROR

CX_ST_NVALD_XML

CX_ST_MATCH

CX_ST_REF_ACCESS

CX_ST_RUNTME_ERROR

CX_ST_SERALZATON_ERROR

CX_XSLT_EXCEPTON

CX_XSLT_SYSTEM_ERROR

CX_XSLT_ABAP_CALL_ERROR

CX_XSLT_DESERALZATON_ERROR

CX_XSLT_FORMAT_ERROR

CX_XSLT_RUNTME_ERROR

CX_XSLT_SERALZATON_ERROR

CX_NO_CHECK

CX_BAD

CX_BAD_CONTEXT_ERROR

CX_BAD_FLTER_ERROR

CX_BAD_NTAL_CONTEXT

CX_BAD_NTAL_REFERENCE

CX_BAD_NOT_SNGLE_USE

CX_BAD_MULTPLY_MPLEMENTED

CX_BAD_NOT_MPLEMENTED

CX_BAD_UNKNOWN_ERROR

CX_SY_EXPORT_BUFFER_NO_MEMORY

CX_SY_GENERATE_SUBPOOL_FULL

CX_SY_LLEGAL_HANDLER

CX_SY_LOCALZATON_ERROR

CX_SY_NESTED_PRNT_ON

CX_SY_NO_HANDLER

CX_SY_PPES_NOT_SUPPORTED

CX_SY_PPE_REOPEN

CX_SY_REMOTE_CALL_ERROR

CX_SY_RMC_COMM_FALURE

CX_SY_RMC_NVALD_STATUS

CX_SY_RMC_SYSTEM_FALURE

CX_SY_TOO_MANY_FLES

Exception Handling in ABAP
What are exceptions?
An exception is an event or in simple terms, an error during the execution of a program that interrupts the normal flow of control.
An exception-handling mechanism makes it possible to deal with these run time errors.
The runtime errors can be of two types:
Catchable Runtime Errors which can be caught using the necessary exception handling.
Non-Catchable Runtime Errors which can not be caught by exceptional handling and always result in termination of program
Classical way of handling Exceptions
In the existing concept, exceptions can be raised via the RAISE statement, and function modules or methods then declare them via the EXCEPTI
ONS clause.
Exception handling is done by mapping each exception name to a number, while calling the function module or method. Then check the sy-subrc
for one of these values once the function module or method returns.
After function call there are two ways of handling:
Handle all of them immediately after a function or method call
Select only certain exceptions for handling and pass on the rest to the caller.
But it's a rather tedious process since you have to do the mapping manually, for all exceptions. Not even it takes lot of effort, it makes the
code unreadable.
New Concept of Exception Handling
Exceptions after release 6.10 use the object oriented concept. They are represented by objects that are instances of classes. Each such class is
called an exception e.g., a division by zero, data conversion etc.
There is a class called cx_root which is the root of all the exception classes i.e. all other classes are inherited from this class. This class can be
used to define handlers for all types of exceptions.
Attributes can be used to store the additional information about the cause of exception so that the exception handlers do not need to know the
exception context.
With the help of Inheritance existing exceptions can be more specifically used by adding new attributes to it.
Exception Categories
The cx_root class is the super class and the classes that are directly inherited from cx_root are as follows:
A cx_static_check is checked by both the compiler and the runtime system such that if any exception of this category occurs and is not
handled locally inside of the procedure, has been declared in the RAISING clause of the procedure's interface (described in later
sections).
A cx_dynamic_check is checked only by the runtime system when exception tries to leave a procedure that it has been declared in the
RAISING clause of the procedure's interface.
A cx_no_check exception can always leave the interface of a procedure. Neither the compiler nor the runtime system performs any
interface checks.
Raising and handling Exceptions
Exceptions are raised to indicate that some exceptional situation has occurred. Generally, an exception handler tries to repair the error, find an
alternative solution or, where this is impossible, bring the system to a consistent state and then pass on the error. If the system cannot find a
handler for an exception throughout the entire call hierarchy, the program terminates with a short dump.
Raising Exceptions
Exceptions can be raised at any point in a method, a function module, a subroutine, and so on. There are two ways a class-based exception can
be raised:
Exceptions raised by ABAP runtime system e.g.
x = 1 / 0.
This will result in a run time error of type cx_sy_zerodivide.
Exceptions raised by programmer.This can be done in two ways:
1. Raise and create an exception object simultaneously.
2. Raise an exception with an exception object that already exists In the first scenario, use the syntax:
RAISE EXCEPTION TYPE <EX_CLASS>
[EXPORTING a1 = ... b1 = ... ]
Values to the exception class constructor can be passed using exporting parameters.
In the second, scenario when an exception object already exists. Use the following syntax
RAISE EXCEPTION exep.
Note that exep must be an object variable bound to an exception object instance.
Catching and Handling Exceptions
Handlers are used to "catch" class-based exceptions. Handlers can be defined in following way:
Handlers are defined for statements in a TRY block.
The TRY block, together with the handlers, is defined by the construct- TRY... ENDTRY
Within the TRY ENDTRY construct, each handler is specified by a CATCH statement followed by the exception class.
The TRY block comprises all statements between TRY and the first CATCH.
The statements following the CATCH clause are executed only if the handler catches an exception.
Each exception is caught only once, by the first suitable handler i.e. if the catch clause lists either the class of the exception or a super
class of it.
A handler consists of all statements between its CATCH clause and the CATCH clause of the next handler (or ENDTRY, if there are no
more handlers).
Each handler can catch more than one type of exceptions i.e. the exceptions of particular class and its subclasses.
The sequence of handlers is important.
If a procedure is called within a TRY block, the appropriate handlers in the corresponding TRY ... ENDTRY construct will also catch all
exceptions that are raised but not caught within that procedure.
If the system cannot find an appropriate handler in a TRY ... ENDTRY construct, it searches for handlers in the next outer TRY ...
ENDTRY construct. if it cannot find an appropriate handler there either, it continues the search. If it eventually finds a handler which may
be several steps upward in the call hierarchy
Syntax:
TRY. "Begin of try block
"Write code here which raises an exception
CATCH <EX_CLASS1> <SUBCLASS1><SUBCLASS2>.
"For catching exceptions of class <EX_CLASS1>
"Including the subclasses. <SUBCLASS1> & <SUBCLASS2>.
"Any no of statements
CATCH<EX_CLASS2>. "For catching exceptions of class <EX_CLASS2>
"Including all the subclasses.
"Any no of statements
CATCH cx_root. "For catching catchable exceptions of all kinds
" Any number of statements
ENDTRY.
Why is the sequence of handlers important?
Suppose there are two handlers with one of the handlers with class cx_root. If the order of the two handlers were swapped, the system would use
the handler for all exceptions of the class cx_root and the other handler would never be used. To avoid this, the compiler always checks that
handlers are listed in the program in ascending order, with respect to inheritance.
The CLEANUP clause.
When a handler catches an exception, the normal flow of control is changed. In many cases, ending procedures prematurely in this way causes
objects to be left in an inconsistent state or prevents resources from being released. In particular, if the system jumps several levels up the
hierarchy, the handler might not be able to take the appropriate corrective measures. For this reason, there is another clause for the TRY
construct: the CLEANUP clause, it consists of the keyword CLEANUP and a number of statements that form the CLEANUP block.
The statements of the CLEANUP block are executed whenever an exception occurs in a TRY block that is not caught by the handler of the same
TRY ... ENDTRY construct, but rather in a surrounding TRY construct. Within the CLEANUP clause, the system can, for example, restore an
object to a consistent state or release external resources.
Each TRY ... ENDTRY construct contains a maximum of one CLEANUP clause. You must include it after the last CATCH and before the ENDTR
Y, if at all
Syntax:
TRY. "Begin of try block
"Write code here which may raise an exception
CATCH <EX_CLASS1> <SUBCLASS1><SUBCLASS2>.
"For catching exceptions of class <EX_CLASS1>
"Including the subclasses. <SUBCLASS1> & <SUBCLASS2>.
. "Any no of statements
CATCH<EX_CLASS2>. "For catching exceptions of class <EX_CLASS2>
"Including all the subclasses.
"Any no of statements
*CATCH *cx_root. "For catching catchable exceptions of all kinds
"Any number of statements
CLEANUP.
"Cleanup block
"Statements to restore consistent state
ENDTRY.
Defining Exceptions
Exception classes can be global or local classes. When creating a global exception class, the Class Builder ensures that its name follows the CX
_ prefix naming convention. Exceptions have some specific properties e.g., each exception has an explanatory text assigned to it that describes
the exception.
Constructors for Exceptions
Exceptions are usually created and raised immediately. After calling the constructor of an exception, you usually do not invoke a sequence of set
methods or attribute assignments. That means that all attributes are usually set via the constructor. Following this observation, the exception
constructor is automatically created as soon as you save the exception class; it has one optional parameter for each non-private attribute.
Texts for Exceptions
Each exception has an explanatory text assigned to it that describes the exception. The text is used for error analysis in error logs or short dumps
and therefore describes the exception from a technical point of view. A good user interface therefore usually catches exceptions and describes
the error from a user point of view, instead of simply forwarding the technical message from the exception object.
For texts to adequately describe an exception, you have to be able to set parameters for them.
Attributes can be included in the text by using the name of the attribute surrounded by "&, "as in "&nameofattribute&.If you want the "&"symbol to
appear in the actual text, you have to enter it twice.
Consider the following example:
'I am with &obj1& && &obj2&'
With the following attributes:
obj1 = 'Ankit'
obj2 = 'Bhuvesh'
1.
2.
Produces the following text:
'I am with Ankit & Bhuvesh'
Attributes and Methods of Exceptions
Exception classes inherit the following attributes from cx_root:
Textid - Used to define different texts for exceptions of a particular class, as explained above. Affects the result of the method get_text
(see below).
Previous - If one exception is mapped to another, this attribute can store the original exception, which allows you to build a chain of
exceptions. if a runtime error occurs, the short dump contains the texts belonging to all the exceptions in the chain. Mapping one
exception to another may be advisable if, for example, the context in which the first exception occurred is important for characterizing the
error situation represented by the second exception (see the upcoming section "Mixed Use of Class-Based and Non-Class-Based
Exceptions"). Exception classes inherit the following methods from cx_root:
get_text - Returns the textual representation as a string, according to the system language of the exception, as explained earlier in the
section "Texts for Exceptions"
get_longtext (available only since 6.20) - Returns the long variant of the textual representation of the exception as a string, in the Class
Builder, you can also specify a long text for each exception ID.
get_source_position - Returns the program name, include name, and line number reached where the exception was raised.
Examples of exception handling
Example1:
Simple usage of the Try-Catch Block.
Description
In this example I have taken two parameters of character type. I am dividing the first parameter by second parameter to get the result in a float
type variable.
There can be two types of exceptions that can be generated in this code.
Number conversion error.
Divide by zero exception.First handler catches cx_sy_conversion_no_number exceptions class and the second handler catches
Cx_sy_zerodivide exceptions
Get_text ( ) method of the exception classes is used to get the description of exception
DATA: result TYPE p LENGTH 10 DECIMALS 3,
ex_ref TYPE REF TO cx_root,
msg_text TYPE string.
PARAMETERS: value1 TYPE char40,
value2 TYPE char40.
TRY .
* divide v1 by v2
result = value1 / value2.
CATCH cx_sy_zerodivide INTO ex_ref.
msg_text = ex_ref->get_text( ).
CATCH cx_sy_conversion_no_number INTO ex_ref.
msg_text = ex_ref->get_text( ).
CATCH cx_root INTO ex_ref.
msg_text = ex_ref->get_text( ).
ENDTRY.
IF NOT msg_text IS INITIAL.
WRITE / msg_text.
ELSE.
WRITE: / 'Result :', result.
1.
2.
3.
4.
5.
6.
7.
8.
ENDIF.
Program flow is as follows:
At selection screen user enters the two parameters' values.
Program divides the value1 by value2.
If division is successful the result is stored in variable 'result'.
If the value2 is 0, an exception of type cx_sy_zerodivide exception is raised by the system. The exception is caught in the
corresponding exception block and msg_text is set with the appropriate error message with the help of method get_text of exception
class.
If characters are given as value1 or value2, an exception of type cx_sy_conversion_no_number, exception class is raised by the
system. The exception is caught in the corresponding exception block and msg_text is set with the appropriate error message with the
help of method get_text of exception class.
If there is any other unknown exception that will be caught in catch for cx_root exception class.
At the end if there is any exception them msg_text will not be initial. So msg_text is printed with the help of write statement.
Else the result variable is printed with the help of write statement.
Example2.
Use of Raising Exception keyword and Cleanup block.
This example is a slight modification to the previous example. In this example If any of the numbers input by user exceeds 1000 an
The calculation is done in a perform which propagates the exceptions of type cx_sy_arithmetic_error to the main program whereas the
exceptions of type cx_sy_zerodivide are handled by perform itself.
Cleanup block is utilized to clear the value of result in case of error.
DATA: result TYPE p LENGTH 10 DECIMALS 3,
ex_ref TYPE REF TO cx_root,
msg_text TYPE string.
PARAMETERS: value1 TYPE I,
value2 TYPE I.
TRY.
IF ABS( value1 ) > 1000 OR
ABS( value2 ) > 1000.
RAISE EXCEPTION TYPE cx_demo_abs_too_large.
ENDIF.
PERFORM calculation USING value1
value2
CHANGING result
msg_text.
CATCH cx_sy_arithmetic_error INTO ex_ref.
msg_text = ex_ref->get_text( ).
CATCH cx_root INTO ex_ref.
msg_text = ex_ref->get_text( ).
ENDTRY.
IF NOT msg_text IS INITIAL.
WRITE / msg_text.
ENDIF.
WRITE: / 'Final result:' result.
*&----------------------------------------------------------------------------------
*& Form calculation
*&----------------------------------------------------------------------------------
FORM calculation USING p_value1 LIKE value1
p_value2 LIKE value2
CHANGING p_result LIKE result
p_text LIKE msg_text
RAISING cx_sy_arithmetic_error.
DATA l_ex_ref TYPE REF TO cx_root.
TRY.
p_result = p_value1 / p_value2.
WRITE: / 'Result of division:', p_result.
CATCH cx_sy_zerodivide INTO l_ex_ref.
p_text = l_ex_ref->get_text( ).
CLEANUP.
CLEAR p_result.
ENDTRY.
ENDFORM. "calculation