Ja, das weiß ich. Allerdings ist es auch so, dass es in diesem Zusammenhang nicht wirklich ein Best-Practice gibt mit den Exceptions. Soll eine Exception wirklich zur Programmflusssteuerung genommen werden oder sollten Exceptions nicht wirklich eine "Ausnahme" darstellen. Das eine Auth. nicht klappt, damit muss man eigentlich immer rechnen - von daher ist die Frage: macht dann hier eine Exception wirklich Sinn um die Auth zu wiederholen.
Wie dem auch sei - man kann sicher beides machen.
Habe allerdings auch die Erfahrung mittlerweile, dass ein Workflow mit begrenzter Verwendung von Exceptions irgendwie hier geeigneter sein könnte. Warum: (gut der Code ist bei weitem nicht optimal) Ich hatte Probleme das User-Event Abbruch zu verarbeiten. Der Upload stoppte einfach nicht, weil in der ersten Schleife dann die 2. Schleife kam. Selbst mit einer Exception konnte ich nicht wirklich nach oben durchbrechen an die Stelle wo abbgebrochen werden sollte. Ich musste halt dann eine neue ExceptionKlasse definieren. Diese wurde in der 1. Schleife aufgefangen und dann ignoriert - nur damit das Programm quasi in die 1. Schleife zurückkommt. Das finde ich doch schon irgendwie sehr sinnfrei und ein Fehler im Workflow.
D.h. allein die doppel while Schleife, auch im Beispielcode ist falsch - soll nur eine sein.
D.h. (verstehe ich dich richtig) Wenn ich zum enum aus dem Beispielcode noch weitere States einfüge wie z.B. UPLOAD_AUTHENTICATION und falls dann der Fall eintritt, dass eine neue Auth. während des uploads notwendig wird, dann wird der Status auf UPLOAD_AUTH. gesetzt. Das Programm erkennt daran, dass es wieder zum Status UPLOAD springen muss und kann so fortsetzen.
