E/A-Fehler in Wrapperklasse

[uligerhardt]

Hallo zusammen!

Ich bastele mir gerade eine kleine Klasse zusammen, die u.a. ein TextFile enthält. Dummerweise reagiert mein Konstrukt anders als erwartet, wenn ich versuche, eine nicht vorhandene Datei zu öffnen. Hier mal meine Test-Unit:

Delphi-Quellcode:

{$IOCHECKS ON}
unit Unit2;

interface

type
  TTest = class
  private
    f: TextFile;
  public
    constructor Create(const AFileName: string);
    destructor Destroy; override;

    class procedure Execute(const AFileName: string); static;
  end;

procedure Test(const AFileName: string);

implementation

{ TTest }

constructor TTest.Create(const AFileName: string);
begin
  inherited Create;
  AssignFile(f, AFileName);
  Reset(f);
end;

destructor TTest.Destroy;
begin
  CloseFile(f);
  inherited;
end;

class procedure TTest.Execute(const AFileName: string);
var
  t: TTest;
begin
  t := TTest.Create(AFileName);
  try
    //
  finally
    t.Free;
  end;
end;

{ Test }

procedure Test(const AFileName: string);
var
  f: TextFile;
begin
  AssignFile(f, AFileName);
  Reset(f);
  try
    //
  finally
    CloseFile(f);
  end;
end;

end.

Wenn ich nun Test('C:\Gibts.nicht'); aufrufe, kriege ich wie erwartet "Datei nicht gefunden." (E/A-Fehler 2). Führe ich allerdings TTest.Execute('C:\Gibts.nicht'); aus, so kommt die Meldung "E/A-Fehler 103.". Kann mir das jemand erklären?

[Bummi]

Delphi-Quellcode:

constructor TTest.Create(const AFileName: string);
begin
  inherited Create;
  AssignFile(f, AFileName);
  if FileExists(AFileName) then Reset(f) else  Rewrite(f);
end;

zudem ist C: direkt seit Vista eine schlechte Idee

[Klaus01]

Hallo,

die 103 erhälst Du weil im Create kein CloseFile ausgeführt wurde.

Das Filehandle existiert und Du versuchst die Datei erneut zu öffnen.
Wenn Du mit der Execute Methode eine andere nicht existierende Datei öffnste solltest
Du dann auch den Fehlercode 2 bekommen.

Grüße
Klaus

[uligerhardt]

Zitat von Bummi:

Delphi-Quellcode:

constructor TTest.Create(const AFileName: string);
begin
  inherited Create;
  AssignFile(f, AFileName);
  if FileExists(AFileName) then Reset(f) else  Rewrite(f);
end;

Damit erzeuge ich die Datei aber, wenn sie nicht da ist, oder? Das will ich nicht, eine Exception ist schon in Ordnung.

Zitat von Bummi:

zudem ist C: direkt seit Vista eine schlechte Idee

Der Pfad war natürlich ein Beispiel.

Zitat von Klaus01:

Hallo,

die 103 erhälst Du weil im Create kein CloseFile ausgeführt wurde.

Das Filehandle existiert und Du versuchst die Datei erneut zu öffnen.
Wenn Du mit der Execute Methode eine andere nicht existierende Datei öffnste solltest
Du dann auch den Fehlercode 2 bekommen.

Grüße
Klaus

Wahrscheinlich bin ich heute blind. Also nochmal: Ich habe folgenden Test-Code:

Delphi-Quellcode:

procedure TForm1.FormDblClick(Sender: TObject);
begin
  Test('C:\Gibts.nicht');
  //TTest.Execute('C:\Gibts.nicht');
end;

Wenn ich den laufen lasse, kommt Fehler 2 (wie erwartet). Wenn ich den Quellcode in

Delphi-Quellcode:

procedure TForm1.FormDblClick(Sender: TObject);
begin
  //Test('C:\Gibts.nicht');
  TTest.Execute('C:\Gibts.nicht');
end;

ändere und neu ausführe, kommt Fehler 103. Warum einmal 2 und einmal 103? Es wird doch in beiden Läufen auf eine Variable f: TextFile erst ein AssignFile(f, AFileName); und direkt danach ein Reset(f); losgelassen.

[himitsu]

Wenn der Constructor fehlschlägt (Exception), dann wird die Klasse gleich wieder freigegeben (Destroy wird aufgerufen).
(Ob das soweit stimmt, würde einem der Debugger verraten)

Die Klasse entspricht also eher diesem: (man beachte das Reset)

Delphi-Quellcode:

procedure Test(const AFileName: string);
var
  f: TextFile;
begin
  AssignFile(f, AFileName);
  try
    Reset(f);
    //
  finally
    CloseFile(f);
  end;
end;

Wie sieht denn die Fehlermeldung hier aus?



Und was passiert bei Folgendem?

Delphi-Quellcode:

destructor TTest.Destroy;
begin
  if TFileRec(f).Mode <> fmClosed then
    CloseFile(f);
  inherited;
end;

// oder
destructor TTest.Destroy;
begin
  //if TFileRec(f).Mode in [fmInput, fmOutput, fmInOut] then
  if TFileRec(f).Mode = fmInput then
    CloseFile(f);
  inherited;
end;

[Klaus01]

Error Code 103:
ERROR_TOO_MANY_SEM_REQUESTS - The semaphore cannot be set again.

die Fehlermeldung bekommst Du weil schon eine Verbindung (Semaphore) zu dem Dateinamen besteht. Weil das CloseFile fehlt.

Wohingegen:
Error Code 2:
ERROR_FILE_NOT_FOUND - The system cannot find the file specified.
Quelle

Lösungen um das zu umgehen stehen bereits in den Posts über diesen.

Grüße
Klaus

[uligerhardt]

Zitat von himitsu:

Wenn der Constructor fehlschlägt (Exception), dann wird die Klasse gleich wieder freigegeben (Destroy wird aufgerufen).
(Ob das soweit stimmt, würde einem der Debugger verraten)

Die Klasse entspricht also eher diesem: (man beachte das Reset)

Delphi-Quellcode:

procedure Test(const AFileName: string);
var
  f: TextFile;
begin
  AssignFile(f, AFileName);
  try
    Reset(f);
    //
  finally
    CloseFile(f);
  end;
end;

Wie sieht denn die Fehlermeldung hier aus?

OK, das ist es. Jetzt, wo ich es auf dem Silbertablett serviert kriege, sehe ich es auch.

Zitat von himitsu:

Und was passiert bei Folgendem?

Delphi-Quellcode:

destructor TTest.Destroy;
begin
  if TFileRec(f).Mode <> fmClosed then
    CloseFile(f);
  inherited;
end;

// oder
destructor TTest.Destroy;
begin
  //if TFileRec(f).Mode in [fmInput, fmOutput, fmInOut] then
  if TFileRec(f).Mode = fmInput then
    CloseFile(f);
  inherited;
end;

Ich habe die erste Variante genommen (mit TTextRec statt TFileRec) und kriege jetzt das erhoffte Ergebnis. Ist eigentlich logisch - ist ja der gleich Grund, aus dem man (mindestens) in Destruktoren Free statt Destroy aufrufen sollte - damit nur tatsächliche allozierte Ressourcen freigegeben werden.

Vielen Dank euch allen!

[himitsu]

Bei dem <>fmClose muß nur uf jeden Fall die File-Variable initialisiert sein, bevor das FileClose auch nur daran denken könnte man dranzukommen.

Es ist oftmals zwar eher unwahrscheinlich, daß ein "billiges" Create (inherited) fehlschlagen kann, aber dennoch würde AssignFile(f, AFileName); noch davor hingehören.
AssignFile selber macht noch keine Dateizugriffe, es initialisiert nur die Variable und legt den Dateinamen (als ShortString) darin ab.
Ohne sichere Initialisierung wäre die Prüfung auf fmInput, fmOutput und fmInOut noch am Sichersten.
Im Falle des Objektes und da dessen Speicher automatisch mit 0/nil initialisiert wird, könnte man auch auf if (TFileRec(f).Mode <> 0) or (TFileRec(f).Mode <> fmClosed) then prüfen und das AssignFile so belassen.

[uligerhardt]

Zitat von himitsu:

Bei dem <>fmClose muß nur uf jeden Fall die File-Variable initialisiert sein, bevor das FileClose auch nur daran denken könnte man dranzukommen.

Die Dateivariable ist als Member einer Klasse ja null-initialisiert. Das ist also kein Problem.

[himitsu]

fmClose ist aber nicht 0
Und der Delphi-Code prüft auch nicht auf 0.

fmClose und Co. sind "komische" Magicnumbers. (als Enum, mit fmClose=0 wären die praktischer gewesen)