Script: ABAP Tools - Debugging for Beginners [006]

Table of contents

• Introduction
• Example
• Breakpoints
• Perspective
• Debugging
• Keyboard shortcuts
• Information
• Change
• Tables
• Exceptions
• Breakpoints
• Soft-Breakpoints
• Statements
• Conclusion

Introduction

In this episode, we look at the topic of debugging. Many developers still have problems using debugging with ABAP development tools. Therefore, in this video, we would like to look at three things in detail.

• Breakpoints - Here, we would like to discuss the different types of breakpoints. Further debugging settings.
• Configuration - Configuring the perspective and the various views for better use of the debugger.
• Execution - Techniques and best practices for debugging with the ABAP Development Tools.

 

Example

In this example, we have created an executable class with several methods. This allows us to run through various debugging scenarios and test the various views in the debugger. In this method, for example, there is an exception that is thrown and passed up through the various hierarchies of methods, where it is wrapped in various other exceptions.

There is also a method that returns data in the form of a table, or a method that creates a JSON string and returns it as a variable. We also have a message class and an exception class, which we won't go into in detail here.

 

Breakpoints

How do we actually set breakpoints in ADT? What types are there? Unlike the SAP GUI, Eclipse doesn't have the /h command to start the debugger via the GUI. In this case, we need to set breakpoints in the source code beforehand.

Here you can set a breakpoint by double-clicking on a line. This automatically sets an external breakpoint, allowing you to debug any calls for the defined user. You can find further debugging settings in the settings, such as the current user or whether you want to debug tool requests. You can also enable and disable the breakpoint via right-click and the context menu. The green breakpoints are so-called soft breakpoints. We'll look at these in more detail later. Once the breakpoint has been set, you can start the interface or, as in this case, start the class using F9.

 

Perspective

When the debugger starts, we switch to the debugging perspective. The system will also ask you if you want to do this, which you should confirm. You can also check the box, as we always want to use the debugging perspective when debugging. The advantage is the arrangement of the views; we can adapt these to our needs. The perspective also represents the biggest obstacle for many developers, as they can no longer find their usual tools.

But let's first look at the perspective in detail. In the upper area, we find the various debugging actions. These behave like the GUI debugger in terms of keyboard shortcuts, so you won't have to make any changes. You can freely position the various views of the perspective, which we'll do next. Let's first create a familiar working atmosphere and rearrange the views. On the left side, we need the complete source code so we have a clear overview. In the upper right section, we want the call stack, and at the bottom, the various variables. Personally, I position the table view and the exception viewer next to these to have access to the most important analysis tools. This gradually gives the view the appearance and functions of the classic debugger. You can easily switch the perspective in the upper part.

 

Debugging

Let's take a closer look at debugging and discuss various points.

 

Keyboard shortcuts

We can navigate through the source code as usual using the function keys. With F5, we navigate into the method and go one step further. With F6, we execute a step, but skip a method if the next step is a method. With F7, we leave the current method and jump behind the execution.

The "Jump" function can be found in the menu above or via the standard shortcut SHIFT + F12. You should also use this function sparingly. As in the SAP GUI, the source code is not executed when you jump forward. If you jump back, variables are not deleted, and this can result in incorrect results in tables. Therefore, you should always use this function with caution. In the menu, you will find additional options for closing the debugger or Run to Line, which are not available in the SAP GUI debugger.

With F8, we let the logic continue running, either until the end is reached or another breakpoint is reached. To return to the coding, all you have to do is change the perspective.

 

Information

If you want to get information about variables and contents, all you have to do is hover the mouse pointer over the corresponding variable while debugging, and the information will appear in a popup. Double-clicking the variable displays it in the corresponding view. Variables, tables, and exceptions are available here.

If the variable contains a specific format, such as a JSON string, you can change the view when displaying the variable. You can right-click to select the appropriate display; in this case, we want the JSON view.

 

Change

If we want to change the contents of a variable, for example, to simulate different inputs or change various parts of the program logic, we first have to bring the variable into the variable view. Clicking on the value or value column starts the change mode. Here we enter the new value and confirm with ENTER or click elsewhere.

 

Tables

There is a separate view for displaying tables. We recommend displaying them directly next to the variables to ensure quick analysis. Let's take a look at an internal table returned by the GET_TABLE_CONTENT method. The view shows us the data in table format. Here, for example, we can adjust the order of the columns, but we can also filter content if we're looking for something specific. In this example, we're searching for Euro in the table, and the rows are highlighted in the view. Visually searching the data is one point. Pressing ENTER also filters the data. We'll do the same thing again for our first example. Changing the content in tables is also possible.

 

Exceptions

Let's take a look at the topic of exceptions. There is also a separate view for displaying exceptions, which gives us further information about the exception and all the exceptions it contains. If there are multiple chained exceptions, we can navigate to the triggering message. In this example, we need to adjust the content of the variable so that the exception is triggered.

Therefore, we set a breakpoint on the IF statement. After starting the debugger, we set another breakpoint before the output in the catch so we can view the exception. The exception has been thrown, and we can view it in the corresponding view. Here we can see the stack of exceptions created and where they were generated. This provides us with further information about the actual error.

 

Breakpoints

Managing the various breakpoints is particularly easy with the breakpoint view. We've placed this next to the callstack in most cases, as we don't always need it. This provides us with information about all set breakpoints, and we can also deactivate or completely delete them centrally if we no longer need them. When we deactivate breakpoints, they are displayed in white in the source code and are still visible in the view. If we then reactivate a breakpoint, it is active again and visible in the code.

 

Soft-Breakpoints

To do this, let's first delete all the breakpoints that have been set. In the overview of the various breakpoints, we also referred to soft breakpoints. These are special points that we can use to pause during debugging. The special thing here is that if no debugger is active, the points are simply skipped. To do this, we set two points in the MAIN method and execute the class. The debugger is not started and the class is run through normally. We therefore set a normal breakpoint in the code and execute the class again. The breakpoint is now triggered and the debugger starts as before. If we continue processing with F8, we also pause at our soft breakpoints. If we deactivate the normal breakpoint again and execute the class, the class will run through to the end again.

 

Statements

Using the Breakpoint View, we can not only get an overview of all set breakpoints, but also set specific points. For example, if you want to break at every IF statement or Message statement, the specific settings are available here in the view. Let's add a new breakpoint for all RAISE statements and check the behavior. This point will also be displayed in the breakpoint overview. To do this, let's stop in the method again and change the content of RAISE_ERROR so that an exception is raised. Every time we press F8, we break at every RAISE statement. This is particularly efficient if we are looking for processing errors but don't know exactly where they are being generated.

 

Conclusion

Debugging with the new debugger will be slower, especially at the beginning. Here, you should set your perspective so that you can access all the information most quickly. It's important to use the debugger continuously to quickly familiarize yourself with it and understand the many additional functions. Personally, we've been working exclusively with the new debugger for about two years, and since we no longer implement reports, we don't miss the /h function, which is especially important for the GUI.

Thanks for sticking around and listening and once again... see you next time.

 

YouTube
Video