Introduction to debugger

What is the ABAP debugger and how can help us.

When a developer creates a program, despite all the help available, whether it be syntax checks or software checks during compilation, it regularly happens that everything is not perfect, and that certain problems have not been considered.

Thus, it is undeniable that the ABAP debugger is primarily a tool for developers to help them avoid this kind of message, which is called "a Dump". Indeed, it is a very important tool that allows to analyze ABAP programs to correct errors, understand the logic and check live the values of a table retrieval.

An example of a DUMP.

Of course, to activate the debugger or to debug something, its not necessary to have a DUMP. We can use the debugger to check how our report extracts data from SELECT or what are the values on a specific IF condition.

SAP offers 2 debuggers:

1. The classic one (not used nowadays). The classic version use the same window for debug as the application. If there are many windows, there is a probability that the classic one will start.

2. The newer version (mostly used). The newer version opens a new GUI window.

How to activate the debugger.

The debugger can be activated by “/h” anywhere, where the command field is available.

On some cases that the command filed is not available we have an alternative way to activate by creating an (file_name).TXT file on Desktop for example and inserting the below code. (Very useful!!)

[Function]

Command=/H

Type=SystemCommand

[!TIP] Helpful when we need to debug a popup.

Change from classic to newer debugger

Because the new debugger uses 2 windows and in most of the systems there is a limit on 5 by default, after closing an opened window we can change back from classic to newer debugger.

Next steps after you activate the debugger and the basic controls.

After activating the debugger, a new window will open. The debugger contains all the information that we may need.

The first row contains the following buttons:

1. Single step (F5)

Single Step: The next operation will be executed, then SAP will stop.

2. Execute (F6)

Execute: The next operation will be executed. Be careful, if the cursor is in front of a block (such as a routine, a module function, etc.), it will be fully executed. SAP will then stop.

3. Return (F7)

Return: The current block (such as a routine, module function, etc.) will be fully executed. SAP will then return to the code that called the executable block.

4. Continue (F8)

Continue: Process the code until the next Break point / Watchpoint. If there is none / no more, the program will be executed in full, and the debugger will close.

5. Go to statement: It is possible to move to a specific location in the code. To move the cursor to the desired location, right click on the desired operation and choose: Goto Statement. Your cursor will then move to that location.

[!TIP] Shortcut for Goto: CTRL + SHIFT + Left Click

Useful information.

There are also other useful information and buttons on top.

1. We can Identify in which line we are.

2. We can check if a SELECT or a condition was success by the number on the field.

3. We can see on what iteration of a loop we are. We can see also on what position a row was inserted or appended into a table etc.

4. If you cannot find the on which line is your cursor, just simple click the button. It will “move” you to the cursor location even if you are on a different stack.

Is there any other way to trigger the debugger?

Except of the “/h” command to trigger the debugger we can also trigger it from the code by creating/putting some breakpoints.

There are different types of breakpoint:

• Session breakpoint

• External breakpoint

There are also different variants of breakpoints:

Type of Breakpoint	Description
Static	A user-specific breakpoint is inserted in the source code as an ABAP statement using the keyword BREAK-POINT. A non user-specific breakpoint is set in the ABAP Editor using the BREAK user name statement.
Directly set dynamic breakpoints	Can be set in the ABAP Editor or the Debugger by double-clicking a line, for example. Dynamic breakpoints are always user-specific, and are deleted when you log off from the R/3 System.
Breakpoints at Statements	The Debugger stops the program immediately before the specified statement is executed.
Breakpoints at Subroutines	The Debugger stops the program immediately before the specified subroutine is called.
Breakpoints at function modules	The Debugger stops the program immediately before the specified function module is called.
Breakpoints at Methods	The Debugger stops the program immediately before the specified method is called.
Breakpoints at exceptions and system exceptions	The Debugger stops the program immediately after a system exception, that is, after a runtime error has been intercepted.

[!WARNING] Avoid to use BREAK-POINT in your code without specify any user. This can cause problem (like stop production flow) in an productive system.