TFileStream.Create vs. FileCreate

[Incocnito]

Moin,

ich habe hier gerade eine Sache, bei der ich echt wahnsinnig werde:

Für einen Locking-Mechanismus hat ein Kollege grob gesagt sowas gebaut:

Delphi-Quellcode:

begin
  Result := nil;
  lOpen := false;
  repeat
    try
      Result := TFileStream.Create('LOCKFILE.DAT', fmOpenReadWrite or fmShareExclusive);
      
      lOpen := true;
    except
      Sleep(200);
    end;
  until lOpen;
end;

Das läuft beim Kunden wunderbar, aber mir geht das auf die Nerven, dass ich ständig Debugger-Exceptions bekomme.
Eine Möglichkeit wäre es disen Exception-Typ zu ignorieren, aber das finde ich noch bescheuerter.
Meine Idee war (wenn der Rückgabewert ein TFileStream sein muss) das so zu erweitern, dass ich vorher einfach
mit FileCreate versuche die Datei zu öffnen und wenn das geht, dann weiter laufen lasse:

Delphi-Quellcode:

  Procedure PreCheck();
  var
    iHdl : THandle;
  begin
    while (True) do
    begin
      iHdl := FileCreate('LOCKFILE.DAT', fmOpenRead or fmShareExclusive);
      if (iHdl = INVALID_HANDLE_VALUE) then
      begin
        Sleep(200);
      end else
      begin
        FileClose(iHdl);
        Exit;
      end;
    end;
  end;

begin
  Result := nil;
  lOpen := false;
  repeat
    try
      PreCheck(); // <- Hier vorab einfach testen
      Result := TFileStream.Create('LOCKFILE.DAT', fmOpenReadWrite or fmShareExclusive);
      
      lOpen := true;
    except
      Sleep(200);
    end;
  until lOpen;
end;

Das hat bei mir wunderbar funktioniert und ich war die lästigen Exceptions los,
aber jetzt rastet das bei den Kunden aus, weil der WindowsDefender auf 100% hoch läuft.
Alles ist langsam. Der Start des Programms dauert ewig. Alles Mist und es macht für mich 0 Sinn.

Was habe ich bitte falsch gemacht?

Mit frunelichem Gruß
Incocnito

[himitsu]

Erst mit CreateFile versuchen die Datei zu öffnen
und wenn erfolgreich in ein THandleStream.

Der Rückgabewert der Funktion als TStream ist sowieso optimaler. (egal was für eine Klasse letzendlich drin steckt)

[Uwe Raabe]

Ich kann irgendwie noch nicht verstehen, wie die repeat Schleife im INVALID_HANDLE_VALUE Fall funktionieren soll, wenn sie mit until (True) abgeschlossen wird.

[jaenicke]

Das macht so überhaupt keinen Sinn. Wenn du die Exception nicht möchtest, öffne einfach selbst das Handle und schließe es nicht wieder. Dann übergibst du das Handle einem THandleStream und schon kannst du deine Anforderung "keine Exception im Fehlerfall" ganz sauber lösen und hast einen Stream wie auch vorher mit dem Filestream.

Denn sobald das Handle zu ist, könnte es jemand anders zufälligerweise öffnen bevor dein Filestream geöffnet wird und deine ganze Vorabfrage ist für die Katz.

[himitsu]

Jooo, WHILE vs. REPAT-UNTIL.

WHILE True = Schleife ausführen wenn True (False = überspringen)
UNTIL True = Schleife beenden wenn True (False = nochmal) ... du wolltest also eigentlich UNTIL False

Bzw., wenn man nicht den Unterschied, sondern die "eigentliche" Gemeinsamkeit betrachten will:
= bei True weiter mit nächster Zeile/Anweisung
* WHILE : in die nachfolgende Schleife rein
* UNTIL : aus der vorhergehenden Schleife raus



Warum mit EXIT rumpfuschen, anstatt direkt UNTIL iHdl = INVALID_HANDLE_VALUE.
Und dann nach der Schleife schließen, bzw. besser direkt an den mehrfach genannten THandleStream.

[generic]

Du kannst im debugger auch nur bei bestimmten exceptions anhalten lassen.
Ich bin leider unterwegs, daher kann ich dir den Menüpunkt nicht sagen.

Es kann sein, dass ich das auch in meinen Tutorial Videos auf YT Mal gezeigt habe.

Edit:
Schau hier Mal die Screenshots an:
Optionen, debugger, ignore exceptions

https://stackoverflow.com/questions/...on-delphi-10-1

[Uwe Raabe]

Zitat von generic:

Du kannst im debugger auch nur bei bestimmten exceptions anhalten lassen.

Ich glaube, das weiß er:

Zitat von Incocnito:

Eine Möglichkeit wäre es disen Exception-Typ zu ignorieren, aber das finde ich noch bescheuerter.

[Incocnito]

Zitat von Uwe Raabe:

Ich kann irgendwie noch nicht verstehen, wie die repeat Schleife im INVALID_HANDLE_VALUE Fall funktionieren soll, wenn sie mit until (True) abgeschlossen wird.

Jaaa, ist ja richtig 😅. Habe das auf while(True)... umgebaut. Mag ich eh lieber als repeat...until(false). 😉

Zitat von Uwe Raabe:

Zitat von generic:

Du kannst im debugger auch nur bei bestimmten exceptions anhalten lassen.

Ich glaube, das weiß er:

Zitat von Incocnito:

Eine Möglichkeit wäre es disen Exception-Typ zu ignorieren, aber das finde ich noch bescheuerter.

Exakt 😁

Zitat von himitsu:

Erst mit CreateFile versuchen die Datei zu öffnen
und wenn erfolgreich in ein THandleStream.

Der Rückgabewert der Funktion als TStream ist sowieso optimaler. (egal was für eine Klasse letzendlich drin steckt)

Ich möchte das lieber nicht ändern, ich finde die TFileStream-Geschichte eh nicht so schön, aber da mein Aufruf da Panik
produziert hat habe ich nun eh Verbot da was einzubauen / zu ändern. Ich hätte nur gerne verstanden warum das nun so eskaliert ist.

Das in den 10 ms zwischen FileClose und TFileStream.Create jemand zwischen grätschen kann ist mir hierfür tatsächlich total egal,
weil vernachlässigbar. Dann greift halt das "alte" Try-Except, was vorher schon da war.

[Uwe Raabe]

Zitat von Incocnito:

Ich hätte nur gerne verstanden warum das nun so eskaliert ist.

Nun ja, mit der oben gezeigten repeat-until-True Schleife (die ja eigentlich keine ist) wird entweder sofort oder nach 200ms das TFileStream.Create aufgerufen. Damit muss der Defender in kürzester Zeit zweimal ran. Das PreCheck löst also nicht das Problem, sondern macht es nur schlimmer.

Wenn du nur Probleme mit der Debugger-Exception hast, dann klammere deine (hoffentlich korrigierte) Lösung doch einfach in ein {$IFDEF DEBUG} . Dann hast du Ruhe und der Kunde bekommt davon nichts mit.

[Incocnito]

Leider wird das Debug-Compilat bei unseren Anwendungen für etwas anderes verwendet.

Die Idee mit dem THandleStream sag gut aus, aber leider gibt der das Handle nicht mehr selbstständig frei.

Jetzt haben die Kollegen hier zeitgleich auch noch in Massen Sachen gebaut, bei dem es in einer Tour zu
Debugger-Exceptions kommt. Mir bleibt ja eh nichts als die jetzt wie alle anderen zu deaktivieren.
Fehlersuchen werden (für mich zumindest) damit nochmal eine ganze Ecke schwieriger.

Um dem Ganzen noch einen drauf zu setzen: Wenn ich mit meiner Funktion das FileCreate "nur" verdoppel,
funktioniert das Tray-Icon vom Programm nicht mehr (er reagiert nicht mehr auf OnClick).
Ich glaube ich mache eine Umschulung als Blumengießer, das ist mir zu hoch.