Article

 

ABAP Runtime Error — Prevention and Detection

by Axel Kurka | SAPinsider

October 1, 2000

by Axel Kurka, SAP AG SAPinsider - 2000 (Volume 1), October (Issue 2)
 
During the preparation for SAP TechEd 2000 in Hamburg, I had to decide on the motto of the ABAP booth. I chose "ABAP - The Business Application Language." I know, I know... I can just imagine what you're thinking about buzzwords like these (I read "Dilbert," too). But the truth is, when making decisions on ABAP design, the ABAP development department always keeps the professional business character of ABAP in mind.

     What's the big deal, you might ask? After all, what is the difference between, say, game programming and business programming? To answer this question from one perspective, let's look at the consequences of "crashes" - for example, in a flight reservation system of an airline, as compared to a computer video game that keeps quitting on you.

     Obviously, children (and adults!) accept the fact that sometimes their PC games terminate. The video game user simply restarts the software. On the other hand, if an airline's flight reservation system or an automaker's supply chain management system runs out of control, there is very little acceptance among the users (to say the least). Availability of the IT systems is crucial in competition. Business software should be designed so that, in most cases, runtime errors can be prevented during development time - not at execution. And, where a system failure does occur, the software should enable the user or the IT staff to manage the problem successfully and quickly. Reliability is even more important than availability.

     Let's start by turning to basic software engineering for a moment. Listing 1 shows a C program code that compiles, runs, and then crashes. The failure occurs because the program tries to access memory (or a segment of memory) that the operating system doesn't allow it to.

main() 
{ 
    char word[10]; 
    int i = 0; 
  
    for(;;) 
    { 
        word[i] = '*'; 
        i++; 
    } 
}
Listing 1 Runtime Error During the Execution of a C Program

     Such failures are called (operating) system exceptions. In the best-case scenario, such a program crash sends to the screen some cryptic information that leaves users clueless. In the worst case, the GUI simply disappears. In either case, these certainly are not good ways to quickly detect the source of the failure. For business software, the bar must be raised much higher.

     You may object that one could easily avoid such nasty crashes if programmers simply obeyed certain rules - if they followed the guidance of books on "faultless programming." (They really do exist, and the author is not Dilbert!) You may also point out the role of testing; extensive testing can minimize the appearance of program failures. But in each case, there is no guarantee that a programmer's pledge of faultless programming, or that even extensive testing, could completely cover the entire functionality of a large software package.¹ Better compilers may help to prevent runtime failures at compilation time as well, but I have never experienced a compiler that prevents programs like Listing 1 from crashing. In any case, there remains some likelihood, no matter how small, that a program written in any programming language will terminate abnormally.

     Unlike gaming software, business software must be prepared to enable a user or the IT staff to detect and handle failures efficiently. But this kind of capability is not free! The software must already be designed to deal with failures. With ABAP - this is the good news - the programmer does not have to worry, because ABAP has these capabilities.

      This article gives you three basic rules of ABAP design architecture, and the ways that ABAP can help prevent and detect such errors. These are rules to help prevent and address ABAP runtime errors - rules that every programmer should know when building software with ABAP.

Design Rule 1: ABAP Must Never Terminate with a System Exception

First things first: if you find that your ABAP program produces a system exception, first be sure that it's an SAP system problem and not your code! This seems to be a little-known fact: ABAP is designed to produce no system exceptions. I sometimes hear that ABAP programmers try to modify their program code after they find, during the testing, that the GUI disappeared - an event that usually signals the abnormal termination of the ABAP program just executed in the backend. (If this does happen, just send an OSS message to our hotline.)

     When you work in ABAP, in contrast to C, you are not able to explicitly allocate or free up memory. Remember that access to memory is always guided by the ABAP Runtime Machine. And programming errors, such as improper access to memory, are also detected by the ABAP Runtime Machine, not by the operating system.

     Take a look at what happens if you run the ABAP program of Listing 2, which does exactly the same thing as the C program of Listing 1.

DATA: word(10) TYPE C, 
       i       TYPE I VALUE 0. 


DO. 
   word+i(1) = '*'. 
   i = i + 1. 
ENDDO.
Listing 2 Runtime Error During Execution of an ABAP Program

     What you would see in this error is that the ABAP program terminates, as it did in C. But this time, it also comes back with detailed error information.

     In C, for example, a program crash detected by an operating system produces a core dump - a snapshot of the relevant parts of memory as it existed when the program crashed ("core" is a synonym for memory). Whenever the exception (e.g., a segmentation fault) that crashes the program occurs, the operating system writes out the core file based on the current state of the running program's address space.

     For the most part, this type of core dump provides pretty useless information for the software user and the system administrator. It is certainly not appropriate information to help a user, system administrator, or programmer repair an error.

     ABAP's alternative offers a solution that does help programmers and system administrators: the ABAP Short Dump.

Design Rule 2: Every Runtime Error Must Produce an ABAP Short Dump

An ABAP Short Dump, shown in Figure 1, includes information in predefined sections, each filled with content for specific types of runtime errors. It provides information such as:

  • What happened
  • What you can do
  • Error analysis
  • How to correct the error
  • System environment
  • User transaction
  • Information on where termination occurred
  • Source code extract
  • Content of system fields
  • Chosen variables
  • Active calls/events
Figure 1 An ABAP Short Dump

     Whenever meaningful, the ABAP Runtime Machine presents information in the logon language. This information is extremely helpful to the system administrator or the programmer (and still, of course, only of limited interest for the software user).

     The ABAP Runtime Machine also allows you to look back at the recent patterns of errors. If you apply transaction ST22, you can access an archive of the ABAP Short Dumps that were written during the last two days - the ABAP dump analysis, displayed in Figure 2. If you need to know what is going wrong with your system, this is the right place to start your research.

Of course, proper error detection during the execution of a program is fine, but prevention is even better.

Figure 2 ABAP Short Dump Analysis

Design Rule 3: Whenever Possible, Detect Program Errors During Compilation - Not During Execution

As an example, SQL syntax errors can be regularly detected during ABAP compilation. If you have ever applied database interfaces like ODBC or JDBC with Java, you will be pleased. The ABAP compiler detects syntax errors in all Open SQL statements (not in Native SQL!).

     Open SQL is the SQL2-compliant database query subset of ABAP. Native SQL - the SQL dialect of the underlying database system - is bypassed by the ABAP compiler and is transferred by the ABAP Runtime Machine, without any parsing, directly to the database machine during the execution time. This, along with the portability of Open SQL code, is a second strong reason for using Open SQL.

     Even if the compiler cannot detect any syntax error, you can find additional hints and warnings about potential errors if you use the Extended Syntax Check (transaction SLIN). (SLIN provides a lot of information on a variety of programming topics - so much, in fact, that it is beyond the scope of this article. For more information, a good starting point is SAP's documentation for transaction SLIN.)

     With these three basic rules of thumb, you are now prepared to find, cure, and prevent errors in your ABAP programming.


¹ By the way, some additional help is on the way. The news from our lab is that we just finished the beta version of a Coverage Analyzer, a new tool that helps ABAP programmers so you can at least determine which parts of a program have been executed. We will have more information on this in an upcoming issue of SAP Insider.
Axel Kurka is product manager of ABAP and GUI at SAP, where he has worked in several development departments. He can be reached at axel.kurka@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!