Entwickler-Ecke

Dateizugriff - AssignFile und try..finally


AScomp - Mo 04.01.10 00:23
Titel: AssignFile und try..finally
Hallo zusammen,

mir steht momentan offensichtlich jemand auf der Leitung:


Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
procedure TFormMain.WriteLogInfo(Info: String);
var
   CreateLogfile: Boolean;
   LogDatei: TextFile;
begin
     CreateLogfile := mkConfig.CreateLog;

     try
        if CreateLogfile then begin
           if FileExists(AppDataDir + 'mk.log'then begin
              AssignFile(LogDatei, AppDataDir + 'mk.log');
              Append(LogDatei);
           end else begin
              AssignFile(LogDatei, AppDataDir + 'mk.log');
              ReWrite(LogDatei);
           end;
           WriteLn(LogDatei, Info);
        end;
     finally
        try
           CloseFile(LogDatei);
        except
        end;
        Application.ProcessMessages;
     end;
end;


Wie kann es sein, dass mir das Programm abstürzt mit der Meldung:

exception class : EInOutError
exception message : E/A-Fehler 32.

main thread ($26c):
007a5314 +0b4 bkmaker.exe UnitMain 1840 +7 TFormMain.WriteLogInfo

Da sind doch wirklich alle Dateioperationen in einer try..finally bzw. try..except - hat jemand eine Idee, weshalb er trotzdem in Zeile 1840 (hier Zeile 12: => Append(LogDatei)) eine Exception erstellt?

Danke schonmal!


Hidden - Mo 04.01.10 00:27

Hi :)

Afaik zeigt der Delphi-Debugger Exceptions auch an, wenn sie durch try..finally eigentlich ausgeblendet werden. Tritt das Problem noch auf, wenn du die .Exe ohne Debugger ausführst? :)

mfG,


AScomp - Mo 04.01.10 00:30

Ja, das Problem tritt auch in der .exe auf - der Fehlerreport kam von einem Anwender.

Es wird MadExcept in der aktuellen Version verwendet, das sollte aber try..except auch richtig deuten und überspringt solche Exceptions dann normalerweise auch korrekt. Denke nicht, dass es an MadExcept liegt.


jaenicke - Mo 04.01.10 00:39

Vielleicht solltest du auch schauen was da passiert, dass die Logdatei noch geöffnet ist beim Schreiben.

Aber was die Exception angeht:
Eventuell kommst du weiter indem du die IO-Checks von Delphi ({$I-} bzw. danach wieder {$I+}) ausschaltest oder die Art der Fehlerbehandlung (SetErrorMode) [http://msdn.microsoft.com/en-us/library/ms680621.aspx] von Windows auf SEM_FAILCRITICALERRORS umstellst.


AScomp - Mo 04.01.10 01:47

Ich vermute, dass der Virenscanner die Datei bei jedem Zugriff scannt - da keine anderen Anwendungen außer meine auf diese Log-Datei zugreifen sollte, kann ich mir das nur so erklären.

Die IO-Checks kann ich zusätzlich mal noch ausschalten, guter Tipp! An der Ursache ändert das natürlich nichts, aber wenn der Virenscanner die Datei geöffnet hat, kann meine Anwendung da ohnehin wenig tun.