---------------------------------------------------------------------------------------------------------------------------------------
Exception:- It is a program abnormal situation or condition where the normal execution flow of the program is disturbed and the programs terminates prematurely with a run time error or short dump in ABAP.
How Exception is raised - It can be raised by the programming code by RAISE EXCEPTION statement or by the RUN time environment.
How it can be Handled- ABAP provided different Exception classes based on the nature or type of exception raised to handle and also with the help of
[ TRY . catch. ENDTRY.] commands.
What if the raised exception is not handled- Whether the exception is raised by the programmer or by the run time environment, if not handled ( more specifically in programming term it is CATCHED ) then it leads to a sort dump those we can see in ST22 transaction.
SAP standard provides some predefined classes those can be used to handle any kind of the exception.
----------------------------------------------------------------------------------------------------------------------------------------
Exception:- It is a program abnormal situation or condition where the normal execution flow of the program is disturbed and the programs terminates prematurely with a run time error or short dump in ABAP.
How Exception is raised - It can be raised by the programming code by RAISE EXCEPTION statement or by the RUN time environment.
How it can be Handled- ABAP provided different Exception classes based on the nature or type of exception raised to handle and also with the help of
[ TRY . catch. ENDTRY.] commands.
What if the raised exception is not handled- Whether the exception is raised by the programmer or by the run time environment, if not handled ( more specifically in programming term it is CATCHED ) then it leads to a sort dump those we can see in ST22 transaction.
SAP standard provides some predefined classes those can be used to handle any kind of the exception.
There are some rules when to use which exception sub class.
- CX_STATIC_CHECK – If the exception is defined as a subclass of CX_STATIC_CHECK, it has to be declared in the method or FM signature. If the exception is propogated from the method or FM, it has to be explicitly declared in all the FM or method signature. If the exception is not declared, it has to be caught. If not caught neither declared, it would result into run-time error.
- CX_DYNAMIC_CHECK – If the exceptions are inherited from CX_DYNAMIC_CHECK, they also needs to be declared in the FM signature. If not, they wont be checked at design time. Generally, all system exceptions like CX_SY_ZERO_DIVIDE begins with CX_SY. All of them are inherited from CX_DYNAMIC_CHECK.
- CX_NO_CHECK – Exceptions that are defined using subclasses of CX_NO_CHECK must not be declared explicitly in the interface of the procedure. The class CX_NO_CHECK and its subclasses are implicitly always declared and are always propagated.
Is this standard exception classes are sufficient to handle any exception or do we need to have own exception classes specific to particular development process.
The Answer is these three exception sub classes are sufficient to handle any kind of exception in OO ABAP but the message we will get will be generic. If we need the messages to be displayed which probably more specific to our development objects then we have to define our own Exception classes and we can not create an exception class as a standalone it has be inherited from either of the three sub classes like CX_STATIC_CHECK / CX_DYNAMIC_CHECK /CX_NO_CHECK.
----------------------------------------------------------------------------------------------------------------------------------------
No comments:
Post a Comment