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
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
int i = 0;
word[i] = '*';
||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
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
Design Rule 1: ABAP Must Never Terminate with a System
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.
word+i(1) = '*'.
i = i + 1.
||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
||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.
||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 firstname.lastname@example.org.