One of the most common requirements for any project is to have a proper exception handling framework. Same goes for any NetWeaver Gateway projects as well.
In this blog, I would elaborate on a basic yet powerful exception handling mechanism which we followed in one of our projects and which assisted primarily in quickly pin-pointing source code where dumps and other issues occurred.
I will leverage the concepts of Dynamic(CX_DYNAMIC_CHECK) and Static(CX_STATIC_CHECK) Exceptions.
Dynamic exceptions are those exceptions which if not declared in FM interface or class methods then they will not be checked during design time. They will not raise any SCI/ATC warning or error.
Static exceptions are those exceptions which if not declared in FM interface or class method and not caught will result into run-time error with full stack trace in transaction ST22. They also raise SCI/ATC warning or error.
How to leverage these age-old concepts with our SAPUI5 applications.
For our solution, I have created two types of exception classes – One which inherits from CX_STATIC_CHECK and another from CX_DYNAMIC_CHECK.
The trick lies in the implementation in the oData classes (DPC_EXT). Here we catch the custom exception (inherited from Static Exception Class) and raise another custom exception (inherited from Dynamic Exception Class) chaining the custom static exception.
This leads to following benefits.
- In case of exception full stack trace is logged in ST22.
- With static exceptions in place, no SCI/ATC error/warnings are bypassed.
Steps are illustrated below.
Step1: Creation of two exception classes
Figure 1: Custom exception class inheriting from static exception
Figure 2: Custom exception class inheriting from dynamic exception
Step2: Implementation of Static Exception Class in classes other than oData classes
Everywhere in the application I have raised and used an exception inheriting from static exception so that it is handled properly in application code. An example below –
Figure 3: Custom static exception used in Business Layer classes
Step3: Type Casting the static exception to dynamic one and raising same in oData classes
Figure 4: Custom dynamic exception used in oData implementation classes
Hoping this blog is useful for quite a few of you and your suggestions are much appreciated.