TFileStream.Create vs. FileCreate

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