Ansicht
Dokumentation

ABENCHAINED_STATEMENTS_GUIDL - CHAINED STATEMENTS GUIDL

Addresses (Business Address Services)   CL_GUI_FRONTEND_SERVICES - Frontend Services  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kettensätze

Aufeinanderfolgende ABAP-Anweisungen, die den gleichen Anfangsteil haben, lassen sich durch einen sogenannten Kettensatz ausdrücken. Ein Kettensatz besteht aus dem einmal angegebenen gleichlautenden Anfangsteil, der durch einen Doppelpunkt (:) abgeschlossen wird, hinter dem die restlichen Teile durch Kommata (,) getrennt aufgeführt werden. Nur der letzte Teil wird mit einem Punkt (.) abgeschlossen. Bei der Syntaxprüfung und der Kompilation wird ein Kettensatz wie die entsprechende Folge einzelner ABAP-Anweisungen behandelt, wobei jedem hinteren Teil der gemeinsame Anfangsteil vorangestellt wird. Die gleichen Anfangsteile sind nicht auf das Schlüsselwort beschränkt.

Kettensätze nur an geeigneten Stellen verwenden

Verwenden Sie Kettensätze hauptsächlich für Deklarationen. Für zusammenhängende Deklarationen der Art TYPES BEGIN OF ... TYPES END OF ...sollen sie in jedem Fall verwendetwerden.

Die hauptsächliche Motivation für die Verwendung von Kettensätzen ist die Erhöhung der Lesbarkeit von Programmen. Dieses Ziel wird bei der richtigen Verwendung in Deklarationen erfüllt. In anderen Anweisungen können Kettensätze die Lesbarkeit eher verringern oder schlimmstenfalls sogar zu falschem Programmverhalten führen. Auch bei der Verwendung von Kettensätzen sollte prinzipiell maximal eine Anweisung pro Programmzeile aufgeführt werden. Keinesfalls sollten Ausdrücke oder funktionale Aufrufe auf mehrere Teile von Kettensätze verteilt werden.

Deklarationen

Für umfangreiche Deklarationen lassen sich Kettensätze gut zur Verbesserung der Lesbarkeit einsetzen. (Zu umfangreiche lokale Deklarationen weisen allerdings auf mangelnde Aufgabentrennung und sollten deshalb nicht vorkommen. Insbesondere können mehrere Kettensätze dazu benutzt werden, zusammenhängende Deklarationen zu gruppieren:

DATA:
   airplane            TYPE REF TO cl_airplane,
   airplane_attributes TYPE cl_airplane=>airplane_attributes.
DATA:
   airport            TYPE REF TO cl_airport,
   airport_attributes TYPE cl_airport=>airport_attributes.
...

Noch wichtiger ist die Gruppierung deklarativer Anweisungen, die semantisch eine zusammengesetzte Anweisung darstellen. So erfolgt die Deklaration strukturierter Typen und Datenobjekte in ABAP über Einzelanweisungen, deren enge Beziehung durch einen Kettensatz ausgedrückt werden sollte:

TYPES:
   BEGIN OF file,
     name TYPE string,
     owner TYPE sy-uname,
     creation_date TYPE timestamp,
   END OF file.

Bei Strukturen, die über die Anweisungen INCLUDE TYPE oder INCLUDE STRUCTURE Komponenten einer anderen Struktur übernehmen, ist dieses Vorgehen nicht durchgängig möglich, da der Anweisungsanfang hier ein anderer ist und so der Kettensatz unterbrochen werden muss. Diese Verwendung der Anweisung INCLUDE wird aber ohnehin nicht mehr empfohlen.

Operationale Anweisungen

Für operationale Anweisungen sind Kettensätze hingegen meist nicht zu empfehlen, da sie hier in der Regel nicht zur besseren Lesbarkeit beitragen. Beispiel:

CALL METHOD meth EXPORTING para = : '1', '2', '3'.

Hier wurde der Umstand, dass die gleichen Anfangsteile vor dem Doppelpunkt nicht auf das Schlüsselwort beschränkt sind, etwas überstrapaziert. Ein besser lesbarer Kettensatz wäre:

CALL METHOD:
meth EXPORTING para = '1',
meth EXPORTING para = '2',
meth EXPORTING para = '3'.

Die beste Schreibweise kommt in diesem Fall aber ohnehin ohne Kettensatz aus:

meth( '1' ).
meth( '2' ).
meth( '3' ).

Unerwartetes Verhalten

Ein falsches Verständnis von Kettensätzen führt leicht dazu, dass syntaktisch richtige Anweisungen mit unerwartetem Verhalten erzeugt werden. Ein Beispiel hierfür sind blockeinleitende Anweisungen innerhalb von Kontrollstrukturen. Hier führt die Verwendung von Kettensätzen im Allgemeinen nicht zum beabsichtigten Ergebnis.

Betrachten wir hierzu die folgende TRY-Kontrollstruktur, bei der die CATCH-Anweisungen über einen Kettensatz realisiert sind:

TRY.
     ...
  CATCH: cx_1, cx_2, cx_3.
     "exception handling
      ...
ENDTRY.

Ein Leser und vermutlich auch der Entwickler dieser Zeilen dürften vermuten, dass es sich um einen CATCH-Block handelt, der drei Ausnahmen behandelt. Tatsächlich sieht die vollständige Syntax aber so aus:

TRY.
     ...
  CATCH cx_1.
  CATCH cx_2.
  CATCH cx_3.
    "exception handling
     ...
ENDTRY.

Die Ausnahmen cx_1 und cx_2 werden zwar abgefangen, die zugehörigen CATCH-Blöcke sind jedoch leer. Lediglich die dritte Ausnahme cx_3 hat einen nicht leeren CATCH-Block. Die vermutlich vom Entwickler beabsichtigte Syntax sieht aber folgendermaßen aus:

TRY.
    ...
  CATCH cx_1 cx_2 cx_3.
    "exception handling
    ...
ENDTRY.

Für die WHEN-Blöcke innerhalb einer CASE-Kontrollstruktur gilt Entsprechendes:

WHEN: a, b, c.

ist nicht gleichbedeutend mit dem wahrscheinlicheren

WHEN a OR b OR c.

Die erweiterte Programmprüfung warnt vor leeren Anweisungsblöcken nach CATCH und WHEN. Auf diese Weise kann durch Verwendung der erweiterten Programmprüfung die missbräuchliche Verwendung von Kettensätzen innerhalb von TRY- und CASE-Kontrollstrukturen aufgedeckt werden.

Ein weiteres Beispiel, bei dem die Verwendung von Kettensätzen leicht zur Falle werden kann, sind die Anweisungen von . Dazu zwei Beispiele:

• Der folgende Kettensatz ergibt aufgelöst zwei SELECT-Anweisungen, die beide jeweils einen Arbeitsbereich mit Werten versorgen und von denen nur die zweite eine WHERE-Bedingung hat.

SELECT SINGLE carrid, connid
       FROM spfli
       WHERE @carrid = '...'
       INTO: @carrid_wa, @connid_wa.

Hier war sicher folgende INTO-Klausel gemeint:

INTO (@carrid_wa, @connid_wa).

• Im folgenden Beispiel aktualisiert auch die scheinbar einzelne Anweisung nicht den Rabatt und die Telefonnummer des Kunden mit der Kundennummer 00017777. Stattdessen handelt es sich um zwei Anweisungen, wobei die erste den Rabatt für alle Kunden und die zweite die Telefonnummer des Kunden mit der Kundennummer 00017777 ändert.

UPDATE scustom SET: discount = '003',
                    telephone = '0621/444444'
               WHERE id = '00017777'.

Selbst wenn in den vorangegangenen Beispielen die Kettensätze die vom Entwickler erwartete Semantik zeigen würden, wird eine solche Verwendung keinesfalls empfohlen, da wohl jeder Leser ein abweichendes Programmverhalten erwarten dürfte und die Lese- und Wartbarkeit des Quelltextes dadurch stark beeinträchtigt wäre.

Ausdrücke und funktionale Aufrufe

Leider können ABAP-Anweisungen sogar innerhalb von Ausdrücken oder funktionalen Aufrufen über den Doppelpunkt in Kettensätze aufgeteilt werden. Das folgende syntaktisch korrekte Beispiel zeigt, wohin das bereits bei einfachsten Ausdrücken führen kann. Das Beispiel dürfte weder verständlich sein, noch dürfte sein Ergebnis irgendwelchen Erwartungen entsprechen.

DATA: itab TYPE TABLE OF i,
      num  TYPE i.

itab = VALUE #(: ( 1 ) ), ( 2 ) ), ( 3 ) ), ( 4 ) ).
num  = itab[: 1 ], 2 ], 3 ], 4 ].

cl_demo_output=>new(
  )->write_data(: `Text1` ), `Text2` ), num
  )->display( ).

ROGBILLS - Synchronize billing plans   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 9939 Date: 20240523 Time: 164530     sap01-206 ( 195 ms )