@mod-poser,
ZitatWenn ich die Fehlernummer erst nach einem RAISE behandle, ist es doch aber so,
daß ein darauffolgendes RETRY den Programmzeiger in der Routine des behandelnden
Errorhandlers auf den Prozeduraufruf stellt, aus dem der der RAISE-Befehl letzendlich, wennauch
über mehrere Prozeduraufrufe und Rücksprünge, gekommen ist.
Ich weiß nicht ob ich dich da richtig verstehe, deswegen laß es mich mal so ausdrücken:
RETRY stellt den Programmzeiger in der Routine des behandelnden Errorhandlers auf den Prozeduraufruf zurück, aus dem der letzte RAISE-Befehl gekommen ist, d.h auf die letzte Routine in der Kette der (Fehler-)weitergebenden Routinen bevor RETRY aufgerufen wird.
RETRY springt also nicht auf den Anfang der ersten, ursprüngliche Routine die den Fehler ausgelöst hat (aber ich denke mal das hast du auch nicht gemeint...)
ZitatWenn man dies geschickt plaziert, weit genug mit RAISE zurückspringen und dann nochmal versuchen,
kann man sich jede Menge Programmiererei ersparen.
Ich denke mal man hat nicht wirklich mehr Arbeit wenn man das vernünftigt mit Funktionen und Rückgabewerten programmiert. Sicherlich könnte ich mir den einen oder anderen Fall vorstellen, bei dem man da ein paar Zeilen spart, aber spätestens wenn es um Fehleranalysen, Dokumentation und dgl. geht, ist man ohnehin meistens gezwungen Statuswerte weiterzugeben, übergeordnet auszuwerten oder sonst was.
Wie auch immer, halte ich die begrenzte/vorgegebene Anzahl der Wiederholungen bei RETRY nach wie vor für die größte Einschränkung.
Ich könnte einen derartigen Kontrollverlust in meinen Programmen einfach nicht hinnehmen... 
good night
Rainer
