@Gargamel:
An sich ist es schon richtig wie du es machst. Allerdings ist es unüblich den Fehlercode über var/out Parameter zurück zu liefern und das Ergebnis per result.
In der Regel wird es genau umgekehrt gemacht. Denn was soll die Funktion zurück geben wenn ein Fehler aufgetreten ist?
Zudem lässt sich bei Fehlercodes per Result einiges etwas kürzer schreiben:
Delphi-Quellcode:
if FunktionsAufruf(Ergebnis) = RES_SUCCESS then
DoAnything;
Ich finde ErrorCodes ganz nett.
Das sagst du nur, weil du das Prinzip der Exceptions nicht in voller Tiefe verstanden hast.
*ALLE* modernen Programmiersprachen setzen auf Exceptions weil es einfach der bessere Weg ist mit Fehlern zur Laufzeit umzugehen.
Delphi Kurs - Exceptions
Exceptions Tutorial
Wenn ich mir die
WinApi anschaue ist da überhaupt nichts mit Exceptions zu finden. Auch so ist es quatsch ressourcenintensive Exceptions zu werfen wenn man auch ohne diese auskommt.
Stell dir vor StrToIntDef etc. würden mit Exceptions arbeiten, und durch abfangen dieser das Ergebnis zurück liefern. Man hätte ganz viel Spaß beim debuggen und langamer wäre das ganze auch.
@FredlFesl: schlechtes Beispiel.
Es ginge auch so:
Delphi-Quellcode:
if Funktion1(aRes) and Funktion2(aRes) and Funktion3(aRes) then
showmessage('success')
else
showmessage(ErrCodeToString(aRes));
oder wenn die Funktion per result den Fehler zurück gibt:
Delphi-Quellcode:
function CheckOK(aRes: Integer; out atErr): boolean;
begin
result := true;
if aRes <> RES_SUCCESS then
begin
aLastErr := aErr;
end;
end;
procedure Test;
var
lErr: Integer;
begin
if CheckOk(Funktion1(aRes),lErr)
and CheckOk(Funktion2(aRes),lErr)
and CheckOk(Funktion3(aRes),lErr) then
showmessage('success')
else
showmessage(ErrCodeToString(lErr));