Wenn diese Frage für mich interessant ist, dann werde ich anders coden. Die Exception ist dann auch nur bedingt hilfreich, denn geh noch einen Schritt weiter und baue gleich zwei innere Tabellenabfragen ein, dann stehste bei einem CX_SY_ITAB_LINE_NOT_FOUND wieder da und weißt nicht, welche fehlgeschlagen ist. Von daher ist das der falsche Ansatz. Wenn diese Information für mich wichtig ist, dann steht es mir frei, in mehreren Schritten zu coden (etwa mit einem eingeschobenen ASSIGN über den inneren Teil, der dann nach Prüfung des SY-SUBRC im LINE_EXISTS verwendet wird). Wenn ich aber alles in einen LINE_EXISTS schreibe, dann sage ich damit deutlich aus, dass nur ich wissen will, ob es so eine Zeile gibt oder nicht und weitergehende Informationen (hier: zum Grund) nicht benötige. Dies zu kritisieren ist wie die Existenz des Zusatzes TRANSPORTING NO FIELDS zu kritisieren, mit dem der Programmierer auch nicht bestreitet, dass es (möglicherweise) einen Zeileninhalt gibt, aber deutlich macht, dass dieser für ihn nicht interessant ist (und er sich daher die Workarea sparen möchte).adt hat geschrieben:Wie du schon angedeutet hast, hat der "getrennte" Ansatz den SAP hier verfolgt, auch sein Gutes: So weiß man dank der Exception wenigstens welcher der beiden Ausdrücke fehlgeschlagen ist.
@adt: Da siehst Du, wohin diese Philosophie führt. Im Kopf von Ralf ist jede nicht existierende Tabellenzeile bereits ein "Fehler". Dabei macht doch gerade die Verwendung der Funktion LINE_EXISTS deutlich, dass das Nichtvorhandensein einer Tabellenzeile mit den angegebenen Kriterien ein durchaus erwarteter und normaler Fall ist, den man nur halt wissen möchte, um adäquat darauf zu reagieren. Dass - sogar innerhalb des LINE_EXISTS, der diese Frage ja ausdrücklich aufwirft - andere nicht gefundene Tabellenzeilen zu einer Ausnahme führen, die unbehandelt sogar zu einem kompletten Programmabbruch führt, führt in Köpfen wie dem Ralfs zu der Wahrnehmung, dass es sich bei solchen immer um "Fehler" handeln müsse.Ralf hat geschrieben:Gerade bei so langen Anweisungen (die eigentlich aus mehreren atomaren bestehen) möchte ich gern wissen, WELCHER Fehler genau auftritt.
DeathAndPain hat geschrieben:Wenn diese Frage für mich interessant ist, dann werde ich anders coden.
DeathAndPain hat geschrieben:Die Exception ist dann auch nur bedingt hilfreich, denn geh noch einen Schritt weiter und baue gleich zwei innere Tabellenabfragen ein, dann stehste bei einem CX_SY_ITAB_LINE_NOT_FOUND wieder da und weißt nicht, welche fehlgeschlagen ist.
Eine Zeile zu einer Bedingung, die nicht existiert. In einem solchen Umfeld ist das Fehlen einer Bedingung sehr wohl eine Ausnahme, die zu melden ist. Alles andere würde ich für einen Implementierungsfehler halten. Weil damit, dass die Bedingung für einen Vergleich nicht existiert, rechnet man offensichtlich nicht, wenn man einen Vergleich macht.DeathAndPain hat geschrieben:Wenn ich aber alles in einen LINE_EXISTS schreibe, dann sage ich damit deutlich aus, dass nur ich wissen will, ob es so eine Zeile gibt
Erstens ist es kein Fehler (im Sinne von falsch), sondern eine Ausnahme (unerwarteter Zustand), das ist etwas ganz anderes (das spreche ich deiner geringen Erfahrung mit Ausnahmen zu), und da du das gern falsch verstehst, müssen wir uns wohl sehr genau ausdrücken. Ja, wenn ich eine Prüfung habe, deren Bedingung gar nicht existiert, dann ist das eine Ausnahme. Definitiv.DeathAndPain hat geschrieben:@adt: Da siehst Du, wohin diese Philosophie führt. Im Kopf von Ralf ist jede nicht existierende Tabellenzeile bereits ein "Fehler".
Du verstehst das nicht zu trennen - die Ausnahme wird nicht geworfen, wenn keine (den Kriterien entsprechende) Zeile vorhanden ist, sondern wenn die Vergleichsbedingung fehlt. Das Problem ist nicht, dass es keine den Bedingungen entsprechende Zeile in BUFFER_DLL_ROLE_ASSIGNMENTS gibt, sondern dass die Bedingung in BUFFER_UNAME nicht existiert. Und das sind zwei voneinander völlig verschiedene Dinge.DeathAndPain hat geschrieben:Dabei macht doch gerade die Verwendung der Funktion LINE_EXISTS deutlich, dass das Nichtvorhandensein einer Tabellenzeile mit den angegebenen Kriterien ein durchaus erwarteter und normaler Fall ist
Das ist aber im Rahmen eines einfachen CATCH nicht so ohne weiteres möglich. Dafür müsste ich richtig Aufwand treiben und einen Ausnahmencontainer definieren, in dem ich mir dann die Ausnahme geben lasse, um deren Details zu analysieren. Am Ende entsteht dann so ein aufgeblähter OO-Code, den keiner mehr versteht. Und wozu? Um mir einen vorausgehenden ASSIGN zu sparen, also eine einzige, gut lesbare Programmzeile (plus nachfolgenden IF), die die Unterbedingung auflösen und die ganze Sache damit wesentlich kürzer und besser lesbar (und nebenbei auch schneller) machen würde! Was Du hier postulierst, ist OO von seiner schlechtesten Seite.Ralf hat geschrieben:Das ist definitiv falsch, du musst in eine solche Exception mal reingucken und du wirst dich wundern, was da alles drinsteht.DeathAndPain hat geschrieben:Die Exception ist dann auch nur bedingt hilfreich, denn geh noch einen Schritt weiter und baue gleich zwei innere Tabellenabfragen ein, dann stehste bei einem CX_SY_ITAB_LINE_NOT_FOUND wieder da und weißt nicht, welche fehlgeschlagen ist.
Das meinte ich im Ursprungstext dieses Threads mit "Ich weiß, man kann das sprachenlogisch begründen". Aus meiner Sicht ist der Knackpunkt in Deiner Aussage aber das Wort "Umfeld". Das "Umfeld" ist die LINE_EXISTS-Funktion, und die nicht existierende "Bedingung" ist eine Tabellenzeile. Wenn aber innerhalb einer LINE_EXISTS-Funktion eine Tabellenzeile nicht existiert, dann weiß ich, welche Reaktion ich darauf haben möchte, und es ist keine Ausnahme!Ralf hat geschrieben:Eine Zeile zu einer Bedingung, die nicht existiert. In einem solchen Umfeld ist das Fehlen einer Bedingung sehr wohl eine Ausnahme, die zu melden ist.
Ich verweise auf mein Beispiel: Es reicht mir nicht, wenn nur der vordere Ausdruck richtig ist, ich möchte auch im "inneren" Ausdruck gemeldet bekommen, wenn dieser falsch ist. Und zwar so detailliert, dass ich die Fehler unterscheiden kann.DeathAndPain hat geschrieben:Wie Du hier argumentierst, ist streng akademisch-theoretisch unter Vernachlässigung praktischer Verwendbarkeitsaspekte.