Zitat von
RavenIV:
Dagegen spricht, dass es ein kalkulierbarer "Fehler" ist und beeinflussbar ist.
Hier ist eine
Exception fehl am Platz.
Ausserdem wäre das zu viel Overhead.
- Einige Exceptions definieren(EPasswortFalsch, EUserFalsch, E...)
- entsprechende
Exception werfen
- Exceptions auffangen
-
Exception auswerten und entsprechend reagieren
Verstehe ich ehrlich gesagt nicht. Beim Anlegen einer Datei ist ein Schreibschutz, Platte voll o.ä. auch ein kalkulierbarer Fehler, der gar nicht so selten ist, wie man vielleicht denkt, ebenso beim Öffnen einer Datei.
- Statt Exceptions definierst du lauter Konstanten.
- Statt Exceptions zu werfen, gibst du Konstanten zurück.
- Statt Exceptions aufzufangen, musst du die verschiedenen Fälle einzeln auswerten (es gibt keine eventuelle Klassenhierarchie wie bei Exceptions, die das Handling vereinfachen, z.B. IOException als Oberbegriff).
- Eventuelle Fehlermeldungen musst du explizit überall bereitstellen, wo die jeweilige Funktion aufgerufen wird.
Und der Overhead, naja, wie oft pro Sekunde wird eine Funktion "Login" aufgerufen?
Ich will hier nichts in Frage stellen. Aber mich interessiert doch die Rationalität, die ich hier nicht wirklich sehe, mit der hier (in diesem Beispiel, nicht in der
DP allgemein
) so kategorisch Fehlermeldungen gegenüber Exceptions bevorzugt werden. Für mich ist eine Funktion Login, was immer diese nun genau macht, ein klassisches Beispiel für einen vorwärtsgerichteten Programmablauf - entweder ist, im Idealfall, alles in Ordnung, oder man muss einen Fehler behandeln, soweit möglich. Wenn man erfolgreich durch ist, muss man die Funktion nicht noch einmal aufrufen - im Fehlerfall vermutlich schon, wenn man sich davon Erfolg verspricht. Da hätte ich persönlich jetzt eine
Exception eingesetzt, in dessen Handler man eben den erneuten Versuch vorbereitet. Je nach Fehler kann man diesen Fehler dann auch relativ unproblematisch an übergeordnete Routinen weiterreichen.
Ich meine, ich höre auch gelegentlich von einigen C++-Programmierern, die soviel Angst vor dem Overhead von Exceptions haben, dass ihr Code früher oder später nur noch ein Wust von Fehlerüberprüfungen ist, aber Delphiprogrammierer neigen doch eigentlich nicht zu sowas
Jedenfalls, in so einem Fall würde ich die
Exception einfach vorziehen. Der Code, weder in der Funktion noch der aufrufende, wird dadurch nicht komplizierter, potenziell wird die Behandlung an dieser Stelle (oder, wichtiger, darüber) sogar einfacher und übersichtlicher.
Falls diese Diskussion nicht hierher passt (naja, irgendwie passt sie relativ gut zur Frage), Antworten gerne auch per PN.