17.4    Using the Debugger to Troubleshoot

Sometimes, it’s difficult to identify problems with programs just by reading the program code. Programs often behave unexpectedly under particular circumstances.

Debugging helps you to check how the program is behaving at a particular moment, under particular circumstances. Sometimes, the problem may not be with the program at all and may be externally generated. For example, the posting program may not be posting the document not due to program error, but due to the wrong data being fed into the program. In such a situation, debugging the program may be the only way to troubleshoot.

Debugging helps troubleshoot any logic errors that are difficult to identify by reading the code. Understanding how to use the debugger tool is just one part; the major skill lies in understanding the program flow and knowing what to debug. If the program is big, you may end up spending hours or even days debugging to identify a problem.

In this section, we’ll provide tips that should help you troubleshoot issues:

• The first step to troubleshooting is to identify where to start. For example, if the program isn’t giving the right output, start with the selection logic.
• Use (F6) to skip debugging unwanted processing blocks. For example, if you come across a function call and you’re sure that the problem doesn’t lie in the function module, press (F6) to skip debugging the function module call. This saves you a lot of time while debugging.
• Check program variables while debugging. It may sound obvious, but many people—especially beginners—debug the whole program without even bothering to check if the program variables are initialized with the right data.
• Check if the program is executing the right control structures. If the program is expected to execute the code in a certain IF condition for the given data, check if that’s happening. If the program variables are initialized with unexpected data, the program logic may fail. This is another reason that you should check if the program variables are initialized with expected data.
• Set and save breakpoints from within the debugger. When executing long programs, you may go through a long list of code before you can zero in on the problem. Setting a breakpoint halfway through may help you to start from where you left off when you rerun the program. However, breakpoints are valid only for the current session, so if you log out from the system or get disconnected, you may have to start from the beginning.
• Use watchpoints to run through the code faster. Want to check how the program is behaving when the 898^th record of the internal table is being processed? Don’t press (F5) until you reach the 898^th loop; use watchpoints to directly jump to that row.
• Use the Breakpoint At option (see Figure 17.24) in the debugger to go directly to a statement or a procedure call if you feel a certain statement or a procedure is causing the issue.
  

  Figure 17.24    Setting Breakpoint

• Want to check why a particular error message or exception is being thrown by the program? Simply place the breakpoint for that message or exception using the Breakpoint At menu (see Figure 17.24), and monitor the program variables to identify what is triggering that exception.
• If you encounter a loop statement, keep a breakpoint outside the loop and press (F8) to continue debugging the program without going through each loop pass.
• Debug only relevant code. If you’re facing issues with a certain task in the application, focus on debugging only the relevant code for that task. Using /H to start debugging from that specific screen may help you understand all the code that’s being executed for that task.
• Short dumps are your best friends. If the program is generating a short dump, read it carefully; it will provide invaluable information about the problem.

These tips should help make you comfortable when troubleshooting problems using the debugger. The more you understand ABAP programming, the better you become at debugging.