INFSR/PSSR

[Squall]

Hm Goto/Tags wollte ich vermeiden aber das mit dem Leave sieht gut aus. Immer noch nicht eine Ideallösung aber ne bessere wirds wohl nicht geben.

Stimmt Java is in der Hinsicht auch nicht viel besser.

Gruß Martin

[Fuerchau]

Das lass nicht die Java-Fraktion hören.

Fehler gehören in den Bereich "Ausnahmen" und müssen eben gesondert behandelt, also aufgefangen werden.
Das Hauptproblem besteht eben in den Prozedur-Aufrufen !
Solange man noch klassisches RPG betrieb konnte man mit *PSSR ganz gut arbeiten. Zumal ja ein EXSR tatsächlich kein echter Unterprogramm-Aufruf ist sondern eine versteckter GOTO.
Das Programm merkt sich für jede BEGSR genau eine Rücksprung-Adresse. Der EXSR setzt die Adresse, der ENDSR führt den GOTO zu dieser Adresse aus. Ein vorzeitiger Return aus einer BEGSR ist nicht möglich.
Deshalb kommt es ja zu Programm-Endlosschleifen, wenn durch zufällige Rekursion der Rücksprung verändert wird.

EXSR R1 // Folge-Adresse merken in XR1

BEGSR R1
EXSR R2 // Folge-Adresse merken in XR2
ENDSR // GOTO XR1

BEGSR R2
EXSR R1 // Folge-Adresse merken in XR1 !!!!!
ENDSR // GOTO XR2

Durch tatsächliche Prozeduren ist das genauso zu sehen wie mit Programm-CALL's.

Wenn nun eine Ausnahme zum Aufruf der PSSR führt, kann diese auch in der untersten Stack-Ebene aufgetreten sein !
Da kann man meist nicht einfach die letzte Aktion wiederholen.

[Squall]

Nun ich habe die letzten 2 Jahre Java programmiert, sowohl in meiner Ausbildung als auch in 2 kleinen Projekten. Theoretischt gehöre, bzw gehörte(da ich jetzt erstmal nur RPG programmiere) ich auch mal zu der Fraktion. Ich programmiere lieber Java als RPG/CL/VARPG aber darüber habe ich ja nicht zu entscheiden. Ich versuch das Beste draus zu machen und die guten Seiten der i5 und der Programmierung darauf zu entdecken.

Ja mit Springen ist das immer soeine Sache. Darum will ich ja wenns geht Gotos vermeiden(exsr sind erstmal ausgenommen, um die komme ich nicht herum).

Gruß Martin

Das lass nicht die Java-Fraktion hören.

Fehler gehören in den Bereich "Ausnahmen" und müssen eben gesondert behandelt, also aufgefangen werden.
Das Hauptproblem besteht eben in den Prozedur-Aufrufen !
Solange man noch klassisches RPG betrieb konnte man mit *PSSR ganz gut arbeiten. Zumal ja ein EXSR tatsächlich kein echter Unterprogramm-Aufruf ist sondern eine versteckter GOTO.
Das Programm merkt sich für jede BEGSR genau eine Rücksprung-Adresse. Der EXSR setzt die Adresse, der ENDSR führt den GOTO zu dieser Adresse aus. Ein vorzeitiger Return aus einer BEGSR ist nicht möglich.
Deshalb kommt es ja zu Programm-Endlosschleifen, wenn durch zufällige Rekursion der Rücksprung verändert wird.

EXSR R1 // Folge-Adresse merken in XR1

BEGSR R1
EXSR R2 // Folge-Adresse merken in XR2
ENDSR // GOTO XR1

BEGSR R2
EXSR R1 // Folge-Adresse merken in XR1 !!!!!
ENDSR // GOTO XR2

Durch tatsächliche Prozeduren ist das genauso zu sehen wie mit Programm-CALL's.

Wenn nun eine Ausnahme zum Aufruf der PSSR führt, kann diese auch in der untersten Stack-Ebene aufgetreten sein !
Da kann man meist nicht einfach die letzte Aktion wiederholen.

[BenderD]

Hallo,

ein paara Anmerkungen von der Java Fraktion:

monitor entspricht ziemlich den try catch Blöcken, ist aber im Unterschied zu Java nicht erzwungen und wird vom Compiler nicht unterstützt.

wenn ich nix mache, saust der Fehler den Call stack hoch (analog zu throws), Unterschied ist wieder die fehlende Unterstützung des Compilers, man muss selber rausfieseln, was da hochgesaust kommen kann.

Condition Handler ist eine Möglichkeit hochgereichte Fehler zu packen, wenn man da einen schreibt, ist das immer noch besser als der des Systems (CPF...), aber halt noch kein Fehlerhandling. Da gilt ähnliches wie in Java, je kleiner der try Block, umso leichter ist das Fehlerhandling zu programmieren; je größer der Block, umso aufwändiger ist es erstmal zu ermitteln, was da eigentlich schief gegangen ist.

zum Java Teil des Threads: man kann natürlich nicht in einen try Block reinspringen und das ist auch gut so!!!

zum RPG Teil des Threads: EXSR und Co sind völlig überflüssig!!! Prozeduren können alles, was man da können muss und sind rundherum überlegen und Vorteilhaft (Lesbarkeit, lokale Variablen etc...)

Dieter Bender,
der entsetzt ist, dass 60 Jahre nach der Erfindung der Lochkarte immer noch Leute auf die Idee kommen mit goto zu programmieren.

Nun ich habe die letzten 2 Jahre Java programmiert, sowohl in meiner Ausbildung als auch in 2 kleinen Projekten. Theoretischt gehöre, bzw gehörte(da ich jetzt erstmal nur RPG programmiere) ich auch mal zu der Fraktion. Ich programmiere lieber Java als RPG/CL/VARPG aber darüber habe ich ja nicht zu entscheiden. Ich versuch das Beste draus zu machen und die guten Seiten der i5 und der Programmierung darauf zu entdecken.

Ja mit Springen ist das immer soeine Sache. Darum will ich ja wenns geht Gotos vermeiden(exsr sind erstmal ausgenommen, um die komme ich nicht herum).

Gruß Martin

[Fuerchau]

Was ist denn eine Kombination aus switch , continue oder break anderes als ein impliziter Goto ?

Bei der Source-Analyse ist der Weg des Programmes bei GOTO meist besser zu verfolgen, als Switch-Verteiler mit Dezimal-Konstanten die von irgendwo quasi angesprungen werden können.

In COBOL kann man sogar per ALTER-Befehl das Sprungziel eines GOTO ändern. Da fragt man sich dann tatsächlich, wo das Programm denn hinverzweigt, da zur Laufzeit über das Ziel entschieden wird.
Zur Compile-Zeit darf sogar kein Ziel angegeben werden:
"Label. goto." und später "alter Label to proceed to NewLabel."

[BenderD]

Hallo,

wenn man kein label angibt (selbst dieser Unfug geht in Java), dann ist es ein Sprung ans Ende eines Blocks, respektive an den Anfang eines Blockes.

Das Problem am Goto (und bei break, continue mit label) ist, dass man an der Stelle, wo der goto steht nicht weiß, ob man nach unten (Typ if), oder nach oben (Typ Schleife), oder ob man gar über Kreuz (Typ irregulär) springt. Zum letzten Typ gehört auch das einspringen in eine Schleife, oder if (kann auch try heißen!!!).

Das mit dem COBOL überzeugt mich nicht, man kann doch nicht als Argument für Unfug anbringen, dass es noch größeren Unfug gibt; das einzige Argument, das ich gelten lassen würde wäre, dass es einen Anwendungsfall mit GOTO gibt, der ohne goto nicht geht, oder schlechter lesbar wäre und das kenne ich bisher nicht.

Zu dem switch construct gibt es immer noch das gute alte if, else if, else if ...mit dem man mehrwertige Verzweigungen abbilden kann.

mfg

Dieter Bender

Was ist denn eine Kombination aus switch , continue oder break anderes als ein impliziter Goto ?

Bei der Source-Analyse ist der Weg des Programmes bei GOTO meist besser zu verfolgen, als Switch-Verteiler mit Dezimal-Konstanten die von irgendwo quasi angesprungen werden können.

In COBOL kann man sogar per ALTER-Befehl das Sprungziel eines GOTO ändern. Da fragt man sich dann tatsächlich, wo das Programm denn hinverzweigt, da zur Laufzeit über das Ziel entschieden wird.
Zur Compile-Zeit darf sogar kein Ziel angegeben werden:
"Label. goto." und später "alter Label to proceed to NewLabel."

[Fuerchau]

Beim C-Switch ist der Case nur ein Einsprung. Ohne Break ist das wie ein Label. If ElseIf kann das so nicht lösen.

[BenderD]

Hallo,

ich dachte zwar an eine mehrwertige Verzweigung...
aber das, was du da hast, lässt sich sehr wohl durch ein verschachteltes if formulieren, obwohl ich das auch schon als (ungewollten) Seiteneffekt gesehen habe, oder nicht ausanalysierte Verzweigungslogik und beides ist fatal.

mfg

Dieter Bender

Beim C-Switch ist der Case nur ein Einsprung. Ohne Break ist das wie ein Label. If ElseIf kann das so nicht lösen.