Step1. Let try the concept of using local exception class which is inherited from the CX_STATIC_CHECK standard exception class.So here we have a exception class- CX_STATIC_EXCEPTION which is inherited from
CX_STATIC_CHECK class. The method VALIDATE_INPUT raises the exception but didn’t declare that exception in the method signature with RAISING clause. So we receive a compilation time warning.
Step2. Now declare the exception type in the method signature with RAISING clause. So it is activated without warning. Now execute this program.
Step3. So we receive a run time error as the raised exception is not caught any where in the method where it is raised or not caught any where in the call hierarchy.
Step4. Now let’s catch the raised exception in the method where it is raised by TRY. CATCH. ENDTRY . code block in the method. Now execute the program.
Step5. So here we caught the exception and after that the statement following the CATCH are executed. So we have the below output.
Step6. Here we are trying to handle the raised exception not in inside the method where it is raised but one step higher in the call hierarchy from where this method is called with the help of TRY. CATCH. ENDTRY code block. Execute the program.
Step7. So here we caught the exception and displayed the message.
Step8. Let’s add a new method SHOW_EXCEP_MSG to the exception class and implement the method. How we call this exception class instance method . SO to call this instance method SHOW_EXCEP_MSG we need an object of the exception class. The object creation of the exception class is conditional in the sense when an exception is raised then only we need to create the object else not. So there is a slight change in the CATCH statement . When a exception is raised the object of that particular exception class is created, then if we add INTO clause to the CATCH statement then the object of the exception class which is created during the RAISE Exception statement is assigned to the reference variable specified after INTO clause in the CATCH command. Then with that object reference we can call the method of the exception class. Execute the program.
Step9. So here we have the below output.
Step10. Let’s add a constructor method to the exception class and implement it. Execute the program and observe how different methods are executed.
Step11. So here we have the below output details.
Step12. Let’s activate the program without the RAISING clause in the method signature ( activate though we have the warning message). The exception is handled not in the method but in the higher call hierarchy from where is is called. Execute the program.
Step13. So here we receive the run time error. This is because the exception is raised but it could not reached from where it is called as the method signature doesn’t have RAISING clause to pass that exception out side of the method implementation. In such a case the exception has to be handled in the same method implementation where it is raised.
Step14. So here we have to handle the exception in the same method implementation in which is it raised as it can not be handled out side of the method implementation.
Step15. So here we have the output.
Step16. Let’s introduce another method RUN which calls the private method VALIDATE_INPUT inside it. The exception is raised in the method VALIDATE INPUT and there is no handler in this method, so the run time environment tries to find a handler in one up the call hierarchy that is in the RUN method. Here also there is no handler and then at last one more up in the hierarchy where RUN method is called. Execute the program.
Step17. So here we have the output.
Step18. This time let’s handle the Exception raised in the VALIDATE_INPUT method , in the RUN method from where it is called. Execute the program.
Step19. Now the exception is handled in the implementation of the RUN method and we have the output.
Step20. If we need to propagate the Raised event to multiple call hierarchy level? The VALIDATE_INPUT method raises an event which is Handled in the implementation of the RUN method and then again the RUN method raises the same exception which is handled in the call of the RUN method.
Step21. So here we have the output when exception is propagated in all the call hierarchy.