ABAP Keyword Documentation → ABAP Programming Guidelines → ABAP-Specific Rules → Checks for Correctness
Syntax Check
Other versions: 7.31 | 7.40 | 7.54
Background
The syntax check provides syntax errors and syntax warnings:
- As soon as a syntax error occurs, the system stops the check and displays the relevant error message. In many cases, the system suggests a correction that you can accept. Programs with syntax errors can be activated, but they cannot be generated and executed. In the extended program check, the syntax errors are reported as fatal errors. Syntax errors must be corrected at all costs.
- If a syntax warning occurs, the syntax check is not terminated. The program can still be executed. The syntax warnings are displayed in the ABAP Editor after the syntax check and the extended program check. Of course, testing tools that include the checks of the extended program check (such as the Code Inspector and the SAP-internal ABAP Test Cockpit) also display syntax warnings. When a program is activated, the system only displays syntax warnings if syntax errors have occurred at the same time. The warnings reported by the syntax check are subdivided into three priorities that are only displayed by the extended program check:
- Priority 1
Errors that could cause program termination if the ABAP program is executed. This priority also includes all constructs that should not be used at all, because they indicate program errors and are very likely to make the program behave incorrectly.
- Priority 2
This priority refers to all constructs that do not necessarily cause incorrect behavior, but are obsolete, for example, and should be replaced by current constructs. Priority 2 errors can become priority 1 errors or syntax errors in future releases.
- Priority 3
Includes all errors where correction would be beneficial, but not necessarily essential, for the current release. However, the possibility of raising the priority in future releases is not ruled out.
The severity of the ABAP syntax check is determined by the decisions that were made when the program was created. In this way, program constructs that produce only syntax warnings outside of classes or in non-Unicode programs, can represent real syntax errors in classes or in Unicode programs. You can suppress selected syntax warnings by using pragmas. A pragma is a program directive that affects specific checks but does not influence the program flow.
The operational package concept means that the syntax check also checks package violations. In this case, whether a syntax error or only a syntax warning occurs depends on the encapsulation level set for the corresponding package.
Rule
Take notice of syntax warnings
Take all warnings of the ABAP syntax check seriously. Syntax warnings are not permitted in completed programs.
Details
You must always correct the causes of syntax warnings because they generally lead to unpredictable errors. These warnings are often reclassified as errors by SAP in subsequent AS ABAP releases. In this case, a program that initially only included syntax warnings is syntactically incorrect and can no longer be used after an upgrade. Exactly the same behavior is displayed when switching from non-Unicode programs to Unicode programs or when migrating older program parts to ABAP Objects.
Selected syntax check warnings can be hidden using pragmas. With respect to the package check, selecting Package Check as Server in Package Builder is the first step to achieving real encapsulation.. It enables users of development objects to modify their where-used positions before hard syntax errors occur. For this reason, all package check warnings must be corrected to ensure that the program's syntax remains correct, even after increased encapsulation of the packages used.
Bad example
The following source code causes a syntax warning. An internal table is accessed using a freely specified key, even though a secondary key with the same components exists. This access performs a linear search.
DATA itab TYPE HASHED TABLE OF spfli
WITH UNIQUE KEY carrid connid
WITH NON-UNIQUE SORTED KEY cities COMPONENTS cityto cityfrom.
...
READ TABLE itab WITH KEY cityfrom = '...' cityto = '...'
ASSIGNING <fs>.
Good example
The following source code corrects the above example. Here, the secondary key is used to access the
table. The access performs a binary search. Hiding the syntax warning using the associated program primkey is not recommended here.
DATA itab TYPE HASHED TABLE OF spfli
WITH UNIQUE KEY carrid connid
WITH NON-UNIQUE SORTED KEY cities COMPONENTS cityto cityfrom.
...
READ TABLE itab WITH TABLE KEY cities
COMPONENTS cityfrom = '...' cityto = '...'
ASSIGNING <fs>.