Ansicht
Dokumentation

ABENASSERTIONS_GUIDL - ASSERTIONS GUIDL

ABENASSERTIONS_GUIDL - ASSERTIONS GUIDL

ROGBILLS - Synchronize billing plans   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Assertions

Mit der Anweisung ASSERT kann in einem ABAP-Programm eine Zusicherung ausgedrückt werden. Eine solche Assertion ist entweder immer aktiv oder durch Zuordnung zu einer sogenannten Checkpoint-Gruppe von außen aktivierbar. Bei Erreichen einer aktiven Assertion wird die zugehörige Bedingung ausgewertet. Bei Verletzung der Bedingung wird je nach Art der Aktivierung:

  • das Programm mit dem Laufzeitfehler ASSERTION_FAILED abgebrochen
  • in den ABAP Debugger verzweigt
  • ein Protokolleintrag erzeugt

Assertions bilden zusammen mit Breakpoints und Logpoints die sogenannten Checkpoints eines Programms, die keinen Bestandteil der Anwendungslogik darstellen, sondern der Entwicklungs- und Wartungsunterstützung dienen.

Assertions verwenden

Überprüfen Sie den Zustand eines Programms an allen Stellen, an denen sich dies anbietet, mittels Assertions auf seine Konsistenz hin.

Jede Programmlogik beruht auf bestimmten Annahmen. Sind diese Annahmen nicht erfüllt, ist das Programm offensichtlich fehlerhaft und eine weitere Programmausführung nicht sinnvoll möglich. In diesem Fall soll die Programmausführung sofort abgebrochen werden, um größeren Schaden, beispielsweise in Form persistierter inkorrekter Daten, abzuwenden. Auf diese Weise können auch solche Fehler frühzeitig aufgedeckt werden, die andernfalls zunächst unentdeckt blieben.

Für eine solche Garantie der Konsistenz ist die Anweisung ASSERT am besten geeignet, da sie direkt mit einer Bedingung verknüpft ist und bei Verletzung dieser Bedingung einen Programmabbruch bewirkt.

Assertions tragen darüber hinaus sehr zur Wartbarkeit des Programms bei, indem sie dem Entwickler ermöglichen, seine Annahmen explizit auszudrücken. Der Leser des Quelltextes ist sich sofort über diese Annahmen im Klaren und kann dadurch die Programmlogik besser nachvollziehen.

Sollte die Überprüfung einer Assertion-Bedingung zu zeitaufwendig sein, können hier die aktivierbaren Assertions eingesetzt werden, die mit Checkpoint-Gruppen verknüpft sind. Diese lassen sich gezielt während der Entwicklung, des Tests oder der Fehlersuche einschalten und werden sonst nicht ausgeführt. Falls es in einem Produktivsystem den Verdacht auf ein Fehlverhalten geben sollte, können aktivierbare Assertions dort dann ebenfalls eingeschaltet werden.

Ausnahme

Zustände, die sich der Kontrolle des Entwicklers entziehen, wie beispielsweise ungültige Aufrufparameterwerte oder die Verfügbarkeit externer Ressourcen, dürfen nicht über Assertions abgeprüft werden. Hier müssen Ausnahmen zum Einsatz kommen, damit der Aufrufer auf solche unerwarteten Zustände reagieren kann.

Beispiel

Folgender Quelltext zeigt einen Programmausschnitt, in dem eine Zeile aus einer internen Tabelle gelesen wird. Die Programmlogik geht hier fest davon aus, dass dieser Zugriff stets erfolgreich ist. Diese Erwartung wird durch die nachfolgende Assertion sowohl zur Laufzeit überprüft als auch für den Leser dokumentiert.

...
READ TABLE items INTO current_item INDEX current_index.
ASSERT sy-subrc = 0.
...






rdisp/max_wprun_time - Maximum work process run time   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 3746 Date: 20240523 Time: 183744     sap01-206 ( 79 ms )