Consider an electric switch board, the electrician relies on the status of each switches and breakers to understand what’s wrong in case the power supply to your living room is faulty. The design of this framework is such that the flow of electricity passes through these gates and any abnormalities result in the status of breakers to move to its error state. In software development too, this is the inherent behavior written into each software framework when the program flow encounters abnormalities which is to move to its error state. Through debugging, we analyze and get deeper understanding of these error states and what causes it.
There is a research paper A review of automated debugging systems: knowledge, strategies and techniques ( link here Ducasse,M., and Emde A. M. ) where its stated that for successful debugging, one needs to possess knowledge of seven attributes which are 1) the knowledge of the intended program function, 2) knowledge of the actual program, 3) knowledge of the programming language, 4) programming expertise, 5) knowledge of the application domain, 6)the debugging method and 7) the errors. From my experience, I have found this to be valid, in the most complex scenarios, we go in with two or three of these attributes but we spend time and debug multiple scenarios and one by one gain the necessary knowledge out of the other seven attributes to finally successfully debug and meet the objectives i.e., to find the issue.
In ABAP, as we deal with data inconsistencies most of the time, the debugging method will mostly remain the same. We usually start analysis from the short dump message in ST22, gather information about the Active Calls and Events, error analysis etc… to get a bearing of the issue at hand. Then, we move on to the source code extract, place the debugger at the line indicated. And start debugging with similar test data. In some scenarios, you may need to know if an object from a particular package or class or programs or implemented interfaces are triggered, all this is possible from the debugger settings by setting Layer Aware Debugger active. You can choose whether the break point stops at entry of these objects or at exit. In the differences tab, you can compare variables to highlight the issue quickly. Or you can automate your debugger actions through the Scripts tab. for e.g. you can run a trace for specific statements using one of many templates.
Most of the time spent in projects will be on the debugger tool, so it would be good to get to know the tool a little better. Most of the consultants I know have developed this muscle memory to quickly switch from standard to desktop 3 . The standard tab of the new debugger was displaying the ABAP and Screen Stack, which is crucial for understanding the program flow. Under the miscellaneous context menu, SAP had even provided debugger tips which I found very interesting. These are a few tidbits of information I thought I’d share about the technique of debugging and a few points from my experience. Check out this old blog post about Debugger scripts since you reached this far in the article: Debugger Scripts (Author unknown, somebody called Stephen from the comments).
