GetLastError und falsche Fehlermeldungen, z.b. in TFileStream

[Der schöne Günther]

Wir meinten beide tatsächlich wohl das gleiche. Ich sehe nur nicht wozu der direkte "GetLastError()"-Aufruf notwendig ist, es gibt ja

Win32Check( CreateFile(..) <> INVALID_HANDLE_VALUE ); oder
if (CreateFile(..) = INVALID_HANDLE_VALUE) then RaiseLastOSError(); Die Fundstelle in TFileStream.Create() ist wirklich gut. Wenn man im Internet nach "tfilestream create getlasterror" sucht findet man auch einen QC-Eintrag bei Embarcadero aber der Server streikt ausnahmsweise mal wieder.


Was ich in der Shoutbox noch meinte war der umgekehrte Fall: Manche WinApi-Routinen rufen SetLastError(ERROR_SUCCESS) nicht auf wenn sie erfolgreich waren. Deshalb sollte man nicht GetLastError() nehmen und einen Fehler annehmen wenn dieser nicht ERROR_SUCCESS (also Null) ist.

[mael]

Zitat von Der schöne Günther:

Wir meinten beide tatsächlich wohl das gleiche. Ich sehe nur nicht wozu der direkte "GetLastError()"-Aufruf notwendig ist, es gibt ja

Win32Check( CreateFile(..) <> INVALID_HANDLE_VALUE ); oder
if (CreateFile(..) = INVALID_HANDLE_VALUE) then RaiseLastOSError();

Z.b. wenn man Fehlermeldungen zusammensetzen möchte: <Meine Fehlermeldung><OS-Fehlermeldung>.
Oder man will einfach auf konkrete Fehlercodes reagieren um z.B. eine Datei die gesperrt war wieder nach x Sekunden zu laden zu versuchen, aber wenn der Dateiname sowieso ungültig ist es lassen.

Zitat von Der schöne Günther:

Manche WinApi-Routinen rufen SetLastError(ERROR_SUCCESS) nicht auf wenn sie erfolgreich waren. Deshalb sollte man nicht GetLastError() nehmen und einen Fehler annehmen wenn dieser nicht ERROR_SUCCESS (also Null) ist.

Ist auch ein guter Hinweis. Vielleicht sollte man das irgendwo in der CodeLib oder so aufnehmen?

[himitsu]

Zitat:

Manche WinApi-Routinen rufen SetLastError(ERROR_SUCCESS) nicht auf wenn sie erfolgreich waren.

Was im Prinzip ja richtig ist, da diese API GetLastError und nicht GetLastStatus heißt.

Aber, wie in der Shoutbox bereits gesagt wurde, sollte/muß man den gewünschten Fehlercode direkt nach der "fehlerhaften" API abrufen und zwischenspeichern, wenn er nicht sofort verwendet wird, damit das Ergebnis nicht eventuell durch eine andere "fehlerhafte" API zwischenzeitlich verändert werden könnte.

Delphi-Quellcode:

constructor EFileStreamError.Create(ResStringRec: PResStringRec; const FileName: string);
begin
  inherited CreateResFmt(ResStringRec, [ExpandFileName(FileName), SysErrorMessage(GetLastError)]);
end;

Hier könnte nicht nur ExpandFileName quer schießen, sondern auch der Constructor, da doch im Begin der Speicher für die Instanz reserviert wird.

[BerndS]

GetLastError wird leider auch dann auf 0 gesetzt, wenn der Code in einer DLL ausgelagert ist und man diesen im Except abfragt.

Wünschenswert wäre es, wenn EFileStreamError um LastError erweitert wird.

Bis dahin verwende ich (wenn möglich) meine eigenen TFSFileStream.

Delphi-Quellcode:

TFSFileStream = class(THandleStream)
  strict private
    FFileName: string;
  public
    constructor Create(const AFileName: string; Mode: Word); overload;
    destructor Destroy; override;
    property FileName: string read FFileName;
  end;

  EFSFileStreamError = class(EFileStreamError)
  private
    FLastError: Cardinal;
  public
    constructor Create(ResStringRec: PResStringRec; const FileName: string);
    property LastError: Cardinal read FLastError;
  end;
  EFSCreateError = class(EFSFileStreamError);
  EFSOpenError = class(EFSFileStreamError);