GetLastError gibt per Definition den letzten Fehler zurück,
aber da ständig irgenwelche Trottel mit SetLastError rumpfuschen und solche arbeiten auch bei Microsoft selber, stimmt das eben nicht immer.
Und mit SetLastError setzt man einen "neuen" Fehlercode, womit er dann der Letzte ist.
PS: 0 ist auch ein "Fehler Code", weswegen es auch einen beliebten Fehler in der Fehlerbehandlung gibt.
Auch kann eine Unterfunktion, einen Fehler auslösen, selbst wenn die Hauptfunktion letztendlich korrekt durchlief.
Beispiel Anhand einer imaginären Dateikopierfunktion ala CopyFile:
Zuerst mal mit GetMem großen Speicher anfragen,
wenn nicht genug
RAM frei, dann nochmal nach kleinerem Speicher fragen (das ging jetzt)
dann über dem Speicher kopieren und fertig.
GetMem sagte nun einmal Fehler, womit der Fehlercode gesetzt wurde
aber CopyFile sagt dennoch TRUE, da ja doch noch kopiert werden konnte.
Vorher SetLastError(0) würde also garnichts bringen.
Somit ist, laut
MSDN für
DeleteFile folgender Code falsch
Delphi-Quellcode:
SetLastError(0);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
if GetLastError <> 0 then
ZeigeFehler(GetLastError);
Denn GetLastError kann auch ungleich 0 sein, selbst wenn alles erfogreich war
und wenn DeleteFile oder eine Unterfunktion intern auch mit SetLastError(0) rumpfuscht, dann würde ein nachfolgendes DeleteFile den Fehler des Vorherrigen verdecken.
Delphi-Quellcode:
B := DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
if not B then
ZeigeFehler(GetLastError);
GetLastError wird nur ausgewertet, wenn
mindestens ein Result FALSE sagte
und nachfolgende DeleteFile werden nicht aufgerufen, wenn vorher was schief lief, denn DeleteFile sagt in der Doku nicht, dass vorherriger ErrorCode erhalten bleibt, im Erfolgsfall.