Rückgabewert für Login-Funktion?

[Yheeky]

Hi,

ich habe eine Klasse und mit der Funktion "Login". Hier möchte ich nicht nur den Rückgabewert true oder false für Erfolg oder Misserfolg zurückgeben, sondern verschiedene "Fehlermeldungen" (z.B. falsches Passwort, nicht vorhandener Benutzername). Wie kann ich das am besten realisieren?

Zur Zeit sieht mein Funktionskopf so aus:

Delphi-Quellcode:

function Login : Boolean;

Könnte natürlich einen Rückgabewert wie Cardinal benutzen und die Fehlermeldungen durchnummerieren, aber das ist sicherlich nicht die beste Lösung, oder?

Wäre super, wenn mir jemand einen Tipp geben kann.

[DeddyH]

Die erste Möglichkeit hast Du ja schon angesprochen (wobei ich persönlich diese am Besten finde). Ein zweite wäre z.B.

Delphi-Quellcode:

function Login(var sMeldung: string): Boolean;

In sMeldung wird dann der entsprechende String hineingeschrieben.

[Medium]

Für so etwas nehme ich sehr gerne Aufzählungen her.

Etwa:

Delphi-Quellcode:

type
  TLoginResult = (lrOK, lrErrorWrongPW, lrErrorUserUnknown, ...);
.
.
  function Login: TLoginResult;

Und dann mit case im Aufrufer hantieren - idealerweise noch resourcestrings dort einsetzen.


Wann immer möglich, vermeide ich Rückgaben über die Parameter, aber auch nur, weil ich es aus logischen Gründen als für "nicht sehr elegant" empfinde. Das hat aber keine technischen Gründe.

[RavenIV]

Also ich würde es so machen, wie bei MessageDlg.
Da wurden Konstanten mrYes, mrNo, mrCancel, usw definiert und einfach durchnummeriert.
Die Funktion MessageDlg gibt dann eine der Konstanten zurück.
über den Konstantennamen kannst Du auf vernünftige Weise darauf zugreifen.
Du hast also nicht "3" als Rückgabe, sondern lrPwdError oder so ähnlich.

Das wird bei Windows auch nicht anderst gemacht.
Seien das nun Windows-Messages, irgendwelche Fehlercode oder sonst was.

Und der grösste Vorteil:
Du kannst dann mit case..of arbeiten, was Du bei Strings nicht kannst.

Man kann dann ja noch zusätzlich als out-Parameter einen Result-Text verwenden.

[Yheeky]

Genau so habe ich es jetzt gemacht 8)
DANKE!

[OregonGhost]

Mal als neugierige Frage an alle: Was spricht gegen eine Exception im Fehlerfall?

[RavenIV]

Zitat:

Zitat von OregonGhost

Mal als neugierige Frage an alle: Was spricht gegen eine Exception im Fehlerfall?

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

[OregonGhost]

Zitat:

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.

[shmia]

Zitat:

Zitat von Yheeky

sondern verschiedene "Fehlermeldungen" (z.B. falsches Passwort, nicht vorhandener Benutzername).

Wobei du dem Benutzer und besonders dem Hacker nie verraten solltest, woran genau der Login gescheitert ist.
Man sollte nur eine ganz allgemeine Meldung ala
"Benutzer / Passwort falsch oder Benutzer wurde gesperrt" oder
"Your account may be disabled or blocked or the username/password you entered is incorrect"
ausgeben.
Und zusätzlich vor der Meldung einen Sleep(1500) einlegen um Brute-force Angriffe zu verhindern.
Von daher braucht auch der Rückgabewert nicht so detailiert sein und es reicht im Prinzip ein Boolean.
Zum Debuggen aber vielleicht doch ganz nützlich.

[OregonGhost]

Zitat:

Zitat von shmia

Zum Debuggen aber vielleicht doch ganz nützlich.

Nur zum Debuggen reicht speziell bei der von dir beschriebenen Vorgehensweise vermutlich auch ein Logeintrag.