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

Delphi-Quellcode:

repeat

Schleife im

Delphi-Quellcode:

INVALID_HANDLE_VALUE

Fall funktionieren soll, wenn sie mit

Delphi-Quellcode:

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:

Zitat von generic (Beitrag 1522233)

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

Ich glaube, das weiß er:

Zitat:

Zitat von Incocnito (Beitrag 1522216)

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

[Incocnito]

Zitat:

Zitat von Uwe Raabe (Beitrag 1522225)

Ich kann irgendwie noch nicht verstehen, wie die

Delphi-Quellcode:

repeat

Schleife im

Delphi-Quellcode:

INVALID_HANDLE_VALUE

Fall funktionieren soll, wenn sie mit

Delphi-Quellcode:

until (True)

abgeschlossen wird.

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

Zitat:

Zitat von Uwe Raabe (Beitrag 1522234)

Zitat:

Zitat von generic (Beitrag 1522233)

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

Ich glaube, das weiß er:

Zitat:

Zitat von Incocnito (Beitrag 1522216)

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

Exakt 😁

Zitat:

Zitat von himitsu (Beitrag 1522224)

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:

Zitat von Incocnito (Beitrag 1522238)

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

Delphi-Quellcode:

{$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.

[freimatz]

Debugger-Exceptions? Was ist das?
Verwendet ihr nicht spezifische Exception für unterschiedliche Fälle? Man kann dann genau diese Fälle im Debugger deaktivieren.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1522282)

Debugger-Exceptions? Was ist das?

Das sind Exceptions, die nur im Debugger angezeigt werden, in der Applikation aber entsprechend behandelt sind, so dass der User nichts davon mitbekommt.

Das mit dem Deaktivieren ist so eine Sache. An manchen Stellen möchte man vielleicht eine EFileNotFoundException nicht sehen, weil sie gefühlt zigmal auftritt und im except ja behandelt wird, an anderen Stellen möchte man den Debugger aber eben doch anhalten lassen.

[Incocnito]

Zitat:

Zitat von freimatz (Beitrag 1522282)

Debugger-Exceptions? Was ist das?
Verwendet ihr nicht spezifische Exception für unterschiedliche Fälle? Man kann dann genau diese Fälle im Debugger deaktivieren.

Ich wollte sprachlich nur unterscheiden zwischen den Exceptions, die der Kunde angezeigt bekommt
(weil es kein Try-Except gibt) ["Laufzeit-Exceptions" oder einfach nur "Exceptions"] und denjenigen,
die "wohl mal kommen können" und dann mit Try-Except abgefangen wurden, somit zum Kunden nicht durchschlagen ["Debugger-Exceptions"].
Zumindest verwenden ich und die Entwickler mit denen ich zusammen arbeite das immer so. Kein Anspruch auf Richtigkeit. ;-)

Im Konkreten Fall bekomme ich die gleiche File-Access-Everything-Burns-Meldung vom FileCreate für die LockDatei (wo das halt mal passieren kann)
und halt für irgendwelche anderen Dateien, wo ich (wie gesagt, amit stehe ich hier wohl alleine da) schon konkreter wissen wollen würde,
dass da gerade irgendwas schief geht.

Edit: ... Ja, genau, was Uwe sagt!

[jaenicke]

Zitat:

Zitat von Incocnito (Beitrag 1522275)

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

Es spricht ja nichts dagegen, eine eigene abgeleitete Klasse zu erstellen, die das anders regelt. ;-)

[Uwe Raabe]

Dann würde ich vermutlich eher von TFileStream ableiten und die Überprüfung im Create gleich einbauen.

[himitsu]

Falls nicht irgendwo nachfolgend "explizit" Funktionen des TFileStream verwendet werden, spricht nichts dagegen die Variablen/Parameter als TStream zu deklarieren.
Dann ist es auch egal, ob TFileSteam, THandleStream, TMemoryStream oder ein anderer Streamnachfahre benutzt wird.

So wie man z.B. auch besser TStrings anstatt TStringList benutzt, womit es dann egal ist, ob eine StringList oder z.B. Memo.Lines beim Aufruf benutzt wird.

Zitat:

Zitat von Incocnito (Beitrag 1522275)

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

Du könntest aber auch das Debug-Profil (BuildConfig) ableiten/kopieren und darin dann die gewünschte "Bedingung" definieren. (Projektverwaltung > Build-Konfigurationen > Debug > Kontextmenü: Erzeugen)

Das

Delphi-Quellcode:

{$IFDEF DEBUG}

bezieht sich ja nicht auf den Profil-Name "Debug", sondern auf das DEFINE/Bedingung "DEBUG", welches im Profil steht. (Projektoptionen > Compiler > Bedingungen)

oder IsDebuggerPresent

[QuickAndDirty]

Zitat:

Zitat von Incocnito (Beitrag 1522275)

Ich glaube ich mache eine Umschulung als Blumengießer, das ist mir zu hoch.

Du hast keine Ahnung wie unintuitiv teuer Baumrecht einem zu stehen kommen kann.