SAP-ABAP Exception Handling Classes and it's Usage in the language when writing ABAP Applications. In this post we are trying to give a brief overview on Exception Handling, at the run time how can we handle the exceptions are important in writing any applications. ABAPers refer this post for more details on Exception Handling. Click on read more to read this article.
SAP-ABAP-Exception-Handling-Classes-and-Usage
SAP-ABAP Exception Handling Classes and it's Usage in the language when writing ABAP Applications. In this post we are trying to give a brief overview on Exception Handling, at the run time how can we handle the exceptions are important in writing any applications. ABAPers refer this post for more details on Exception Handling.
Exception Handling:
Exceptions are runtime anomalies or unusual
conditions that a program may encounter while executing. Anomalies might include
conditions such as division by zero, running out of memory. When a program
encounters an exceptional condition, it is importing that it is identified and
dealt with effectively.
Types of Exception Handling in
ABAP
- Exceptions in
function modules
- Class based
exception handling.
Advantages of class based
exception handling:
When an exception object is generated and an
exception is raised or thrown, the exception serves two functions:
- It changes the control flow.
- It carries information about the
details of the error.
Types of raising exceptions
·
Those raised by the runtime system, if a error is detected.
·
Those generated explicitly in the ABAP code.
Steps in raising an
exception
- Creation of exception object
- Propagation along call chain until suitable handler is found(change of control flow)
- If no handler is found: short dump
Exception class hierarchy:
All the Exception classes inherit
from CX_ROOT.
Static_check
For all the exception objects which are of
type cx_static_check compiler checks whether it is caught or propagate to the
calling method otherwise a compile time error is raised.
Dynamic check:
For exceptions of type cx_dynamic_check
compiler doesn’t check whether it is handled or not. At runtime if exception a
raised, if it is caught or propagated program execution continues otherwise
short dump.
If exceptions of this type are not handled in current method but
handled in calling method then we need to explicitly use raising clause in the
method signature of current method.
No check:
For exceptions of type cx_no_check runtime
environment automatically propagates exception to the calling method.
Issues while propagating exceptions:
For exceptions of type cx_static_check if
not handled or propagated compiler raises error. For exceptions of type
cx_dynamic_check if exceptions are not propagated then runtime environment
gives short dump.
For exceptions of type cx_no_check runtime environment
automatically propagates exception to calling method.
Exceptions in method redefinition:
As we are not allowed to change the
interface of the redefining method we are not allowed to use raising clause in
the method interface. So we cannot propagate new exceptions other than those
declared in the parent class method interface.
Try Endtry:
All the code between
try and first catch statement are in protected area. We
are allowed to use any no. of catch statements in a single try block.
Try-endtry can be nested. For every try-endtry we can use only one cleanup
block.
CLEANUP Block:
CLEANUP block can be defined in each
TRY-ENDTRY structure. If the system has not found a handler for an exception,
but the exception is handled in an enclosing TRY-ENDTRY structure or is
propagated to a caller, the Cleanup block is executed before the TRY-ENDTRY structure
is exited.
Handling Exceptions:
try.
catch cx_root.
catch cx_static_check.
endtry.
While handling
exceptions catch blocks should be arranged from child to parent otherwise
compile time error. Above code gives compile time error.
Attributes of
Exception Class:
The attributes of exception classes are
used to transport additional information on an error situation to the handler.
The main piece of information is, however, always the fact that an exception of
a particular class has occurred. The following attributes are inherited from
CX_ROOT:
TEXTID
Used to specify the exception of a class
more precisely by using several exception texts. Is evaluated in the GET_TEXT
method.
PREVIOUS
If an exception is
mapped to another exception, a reference to the original exception can be
defined in this attribute via the EXPORTING addition of the RAISE EXCEPTION
statement and by means of the IMPORTING parameter of the constructor with the
same name.
This can result in a chain of exception objects. In the event of a
runtime error, the exception texts of all the exceptions in the chain are
output.
Mapping an exception to another exception is only beneficial if the
context in which the original exception occurred is important for
characterizing the error situation.
KERNEL_ERRID
The name of the
associated runtime error is stored in this attribute if the exception was
raised by the runtime environment.
Some Frequently used exception classes:
Stattic check:
·
CX_CLASS_NOT_EXISTENT.
·
CX_ABAP_DATFM_INVALID_DATE
Dynamic check:
·
CX_SY_MOVE_CAST_ERROR
·
CX_OS_CLASS_NOT_FOUND
·
CX_SY_TAB_RANGE_OUT_OF_BOUNDS
·
CL_ABAP_CLASSDESCR
No check:
·
CX_SHM_OUT_OT_MEMORY
Note Points to Remember:
- Exceptions
cannot be propagated by static constructors and event handler methods.
- Exceptions whether they are static or dynamic occur at runtime only.
- Cx_root,
cx_static_check, cx_dynamic_check are abstract classes.
- It is a good
programming practice to declare exceptions in the method signature. This
helps users of the method know what exceptions this method may raise.
Dear ABAPers if you know any other points or interview questions related this exception handling topic please drop a comment in the below comment box.
"You found the information helpful and want to say thanks? Your donation is enough to inspire us to do more. Thanks a bunch!"
Posted in: 
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.