TFileStream.Create vs. FileCreate

[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.

[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 von freimatz:

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 von 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.

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 von Incocnito:

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 von Incocnito:

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 {$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 von Incocnito:

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.