Exporting-Parameter wird nicht initialisiert?!?

Re: Exporting-Parameter wird nicht initialisiert?!?

gtoXX hat geschrieben: ↑

08.05.2023 22:45

Nur weil deine Erwartung eine andere ist, ist sie deswegen nicht richtig. Zumal dein Performance-Argument absolut falsch ist. OO ist in keinem Stück Laufzeit intensiver.

Ist das so? Dann lies doch mal mit 7.40er-Syntax die Zeile einer internen Tabelle und reagiere darauf, wenn die entsprechende Zeile nicht gefunden wird. Einmal mit
und einmal mit
Und dann miss mal die Laufzeit beider Versionen für den Fall, dass es die Zeile nicht gibt. Dass ABAP in letzterem Falle ein EXCEPTION-Objekt erzeugt, kostet so dermaßen viel Zeit, dass es kaum zu glauben ist. Da wäre auch ein einfacher oldschool READ TABLE mit nachfolgender Prüfung des SY-SUBRC um Größenordnungen schneller.

Klar wird man das bei einer einzelnen Feldzuweisung nicht wirklich wahrnehmen. Aber solche Zuweisungen stehen ja gerne mal in LOOPs und werden dadurch ggf. tausende Male durchgeführt. Und dann ist das durchaus wahrnehmbar, wenn der Anteil der Fälle, bei denen es die Zeile nicht gibt, nicht nur geringfügig ist.

OO hat nur da nicht zu strukturierterem Code geführt weil die meisten die ABAP programmieren überhaupt keine Ahnung von Programmierung haben. Ich hab genug Leute mit >25 Jahren erfahrung gesehen die nur eines können : User-exits bedienen. Von Software-Architektur 0 Ahnung. Von OO , egal welchem 0 Ahnung. SAP größter Fehler war es überhaupt den alten Schrott lauffähig zu halten. Denn diese Leute können nicht mal saubere prozedurale Programmierung.

In Teilen gebe ich Dir da durchaus recht. Aber bei herkömmlicher Programmierung hat man eine recht gute Chance, sich durch Debugging die Funktionsweise des Codes zu erschließen. Bei OO kannste das in vielen Fällen vergessen. Wenn es keine sehr gute Dokumentation jedes einzelnen Objektes und seiner Attribute gibt, die genau das Sollverhalten des Objektes und Bedeutung der Attribute erläutert, dann versteht man nicht, was da passiert. Und dass in der Praxis niemand diese (erforderliche) Doku schreibt, das wissen wir alle.

Und auch wenn viele Leute strukturierte Programmierung nicht wirklich drauf haben, ist doch irgendwo das Prinzip in die Köpfe gehämmert worden, dass globale Variablen böse sind und nach Möglichkeit nicht verwendet werden sollten. Bei OO hingegen hat man sie - umbenannt in "Attribute" - für offiziell salonfähig erklärt, so dass sie seit OO wieder in Massen angewandt werden und man häufig sogar völlig parameterfreie Methodenaufrufe sieht.

EXPORTING ist vor allem einer Sache geschuldet : Ich muss es nicht abfragen, wenn ich es nicht will. CHANGING aber ist Pflicht, wenn es nicht optional deklariert wurde. Ergo hast Du die Logik noch nicht ganz verstanden ^^

Wenn Du glaubst, dass das der (gewollte) wesentliche Unterschied zwischen EXPORTING und CHANGING sein soll, dann bist Du derjenige, der hier ganz gewaltig etwas nicht verstanden hat.

Nun aus deiner Sicht gibt es keinen Sinn. Weil Du bei Exceptions die Resumable Option vergisst, auch wenn diese seltener genutzt wird. Es macht absolut Sinn das der alte Wert exakt so bleibt. Ich führe eine Option mit Fehler aus, catche den Fehler und setze die Ausführung fort. Das würde keinen Sinn machen, wenn mein Wert auf einmal weg wäre.

Bei einem CHANGING-Parameter würde ich Dir recht geben. Bei einem (aus Aufrufersicht) IMPORTING-Parameter hingegen macht der Aufrufer durch das IMPORTING (anstelle von CHANGING) deutlich, dass das Feld keinen alten Wert besitzt, der nach dem Aufruf noch irgendeine Relevanz besitzt. Wenn das im Einzelfall mal anders sein sollte, solltest Du die Methode mit einem temporären Feld für den Rückgabewert aufrufen.

Und man kann sich das auch sehr gut zu Nutze machen. Z.b. wenn man mehrere Zeilen einer Tabelle validiert. Ich schreibe einen Service der Inhalte validiert. z.b. bei einer Schnittstelle. Mein Service löst immer einen Fehler aus, wenn eines der Felder nicht passt. So kann ich ganz leicht ermitteln welche validen Werte übrig bleiben.

Ich schreibe mir vor dem Catch die fehlerfreien Werten per INSERT in eine Tabelle TAB_FEHLERFREI oder lösche einfach die Zeile aus meiner internen Tabelle im Catch. Trotz EXCEPTION bleibt mir der Inhalt erhalten, weil die Exception resumable ist. Danach verarbeite ich die Fehlerfreien Sätze, informiere den Anwender über die Fehlerhaften. Mit minimalem Coding-Aufwand.

Wo ist das Unsinn ?

Wenn ich Dich richtig verstehe, redest Du davon, dass Dein Service (a.k.a. Methode) die TAB_FEHLERFREI kumuliert und als EXPORTING-Parameter zurückliefert und Du, wenn es nach 20 fehlerfreien Werten zu einem fehlerhaften kommt, nicht die ganze Tabelle verlieren möchtest. Dagegen ist nichts einzuwenden, denn Du schaust hier ja aus Sicht des Unterprogramms, das die TAB_FEHLERFREI aufbaut.

Wenn allerdings der Aufrufer, der am Ende die Tabelle fehlerfreier Werte importieren möchte, Interesse daran hat, was vorher in der internen Tabelle dringestanden hat, die er Deinem Service zum Füllen übergeben hat, dann macht dieser Aufrufer in der Tat einen Fehler.

Es sei denn, Du meinst das so, dass der Aufrufer Deinen Service Wert für Wert aufruft und Dein Service bei jedem fehlerfreien Wert immer eine Zeile in der Tabelle ergänzt. Das wäre für mich aber ein klassischer Anwendungsfall eines CHANGING-Parameters.

Re: Exporting-Parameter wird nicht initialisiert?!?

Normalerweise nicht, nein. Manchmal mache ich eine "Erweiterte Programmprüfung", um meinen Code nochmal aufzuräumen (nicht verwendete Felder usw.).

Re: Exporting-Parameter wird nicht initialisiert?!?

Die Sache ist die, dass ich in manchen Punkten so meine eigene Meinung habe, was programmtechnisch sinnvoll bzw. vertretbar ist und was nicht und SLIN insofern nicht als das Maß aller Dinge ansehe.