Rewrite(f) findet File nicht...

[calibra301]

Komisches Verhalten...

In einem Programm werden regelmässig nach schliessen eines Settings - Dialoges
Daten weggespeichert.
Die Prüfung ob File offen oder existiert schlägt nicht an.
Nur die Rewrite - Exception kommt mit einem "EIOnOutError, Datei nicht gefunden.." und ein 0Kb File bleibt.

Mal geht's X mal gut, dann wieder nicht.

Delphi-Quellcode:

function  CDevice.storeSettings(name: string) : integer;
var i:integer;
    f: file of TSettingsFile;
    s: TSettingsFile;
begin
  storeSettings := -1;
   try
    if IsFileInUse (name) then
    Begin
      MessageDlg('File '+name+' is open !!', mtInformation,  [mbOk], 0);
    end;
     AssignFile(f, name);

    if not fileexists (name) then
    Begin
      MessageDlg(' Gibts nicht !!', mtInformation,  [mbOk], 0);
    end;

     rewrite(f);
  except
    exit;
  end;
  //...diverses Speichern
  Closefile(f)

Suche seit Tagen einen sicher eigenen Fehler und sehe meinen eigenen Blödsinn nicht.
Kann es mit der typisierten Datei zusammen hängen ?

[zeras]

Wenn du schon merkst, dass das File in Benutzung ist, dann darft du nicht einfach weitermachen. Du musst erst warten, bis das File nicht mehr in Benutzung ist.

Delphi-Quellcode:

 if IsFileInUse (name) then
    Begin
      MessageDlg('File '+name+' is open !!', mtInformation, [mbOk], 0);
    end;
     AssignFile(f, name);

sondern so:

Delphi-Quellcode:

 if IsFileInUse (name) then
    Begin
      MessageDlg('File '+name+' is open !!', mtInformation, [mbOk], 0);
      Exit;
    end;

und dann später neu versuchen.

[Sir Rufo]

Warum so kompliziert? Kurz, knapp, erläuternd, auswertbar, ...

Delphi-Quellcode:

if not FileExists( name ) then
  raise EInOutError.CreateFmt( 'File %s does not exists!', [name] );
if IsFileInUse( name ) then
  raise EInOutError.CreateFmt( 'File %s is open!', [name] );

AssignFile( f, name );
RewriteFile( f );

Und im Ganzen

Delphi-Quellcode:

function CDevice.storeSettings(name: string): Integer;
var i:integer;
    f: file of TSettingsFile;
    s: TSettingsFile;
begin
  if not FileExists( name ) then
    raise EInOutError.CreateFmt( 'File %s does not exists!', [name] );
  if IsFileInUse( name ) then
    raise EInOutError.CreateFmt( 'File %s is open!', [name] );
  AssignFile(f, name);
  try
    rewrite(f);
    //...diverses Speichern
    Result := ...
  finally
    Closefile(f)
  end;
end;

[calibra301]

Hi,

danke fürs schnelle Feedback. Habs mal so weit umgebaut.
Des weiteren Breakpoints beim CloseFile und bei jedem Assignfile was das Projekt hat
gesetzt um sicher zu gehen das das File nicht an anderer Stelle geöffnet wird.

Das erste mal läuft sauber durch , auch das CloseFile wird angesprungen.
Beim nächstem mal geht's in das "File is open.."
Was nun tun...nach Filenamen Zwangsschliessen ??

Delphi-Quellcode:

function  CDevice.storerSettings(name: string) : integer;
var i:integer;
    f: file of TPSettingsFile;
    s: TSettingsFile;
begin
  storerSettings := -1;

  if not FileExists( name ) then
     raise EInOutError.CreateFmt( 'File %s does not exists!', [name] );
  if IsFileInUse( name ) then
  Begin
     raise EInOutError.CreateFmt( 'File %s is open!', [name] );
     exit;
  end;
  AssignFile(f, name);
  rewrite(f);

  try
   s.magic := $537916;
   //...usw.
   write(f, s);

  except
   exit;
 end;

 Closefile(f);
 storeSettings := 0;
end;

Danke und schönen Sonntach :-)
Cali

[Sir Rufo]

Wenn du eine

Delphi-Quellcode:

Exception

wirfst, dann wird der Code danach nicht mehr ausgeführt. Ein

Delphi-Quellcode:

Exit

dahinter ist überflüssig.

Delphi-Quellcode:

try

except
  Exit;
end;

ist so mit das Schlimmste, was man machen kann. Das geht in Richtung Quanten-Computer => ja, nein, eventuell vielleicht (warum auch immer oder nicht)

Warum hast du mein Code-Gerüst so verunstaltet? Damit würdest du wissen ob etwas falsch läuft und die Datei würde immer korrekt geschlossen werden.

[calibra301]

Hallo,

habs mit deinem "Gerüst" versucht.

Hat die Funktion bei FileIsopen per Exception verlassen
so wie er es wohl auch sollte.

Nur hab ich damit das Problem nicht vom Tisch..

Wie gesagt, beim erstem mal Klappts , incl. Closefile
Beim zweitem Mal knallt ab Rewrite(f), File is open wurde also NICHT detektiert und ASsignfile ist durchgelaufen.
Beim allen folgenden geht's in deine Exception "File is open"

[Sir Rufo]

Jupp, das

Delphi-Quellcode:

try

war mir eine Zeile zu tief gerutscht ;)
Hab es im Beitrag korrigiert.

[calibra301]

@Rufo...Stadthagen ??
Da brauche ich ja nur mal laut ausm Fenster zu rufen...bin aus Rosenhagen, hinter Wiedensahl :-)

[Sir Rufo]

Zitat:

Zitat von calibra301 (Beitrag 1311595)

@Rufo...Stadthagen ??
Da brauche ich ja nur mal laut ausm Fenster zu rufen...bin aus Rosenhagen, hinter Wiedensahl :-)

Wenn der Kanal da mal nicht das Rufen verschluckt ... ich höre hier nix :mrgreen:

[calibra301]

Welche Chancen hab ich denn das als offen detektierte File zu schliessen
und zu löschen ?

Nicht das sich rausstellt das das alte D6 und W7 bei irgendwelchen Fileoperationen nicht das machen
was sie sollen...

Eim "Umzug" mit diesem Projekt (DLL, incl . Alphatools ) wird bestimmt auch nicht ganz ohne sein.

[FarAndBeyond]

Zitat:

Wenn du eine Exception wirfst, dann wird der Code danach nicht mehr ausgeführt. Ein Exit dahinter ist überflüssig.
try
except
Exit;
end;
ist so mit das Schlimmste, was man machen kann. Das geht in Richtung Quanten-Computer => ja, nein, eventuell vielleicht (warum auch immer oder nicht)

Das liegt aber stark daran wo man sich gerade befindet. Wenn ich im OnClose der Form noch was speichern möchte und es kommt zu einer Exception, dann bleibt ohne EXIT ein Teil des Programms im "TaskManager" hängen, da OnDestroy nicht mehr durchlaufen wird.

In diesem Beispiel sorgt EXIT dafür, dass Closefile(f); nicht mehr durchlaufen wird, was also ungünstig ist...

In D7 wird nach einer Exception der Code innerhalb von Try .. Except nicht mehr durchlaufen, aber der restliche Code innerhalb der Prozedur wird ganz normal durchlaufen...

[calibra301]

Gebe erstmal auf....

Keinen Plan....

Komisch: Nach dem erstem speichern was ja klappt hab ich versucht die Datei
per Explorer zu löschen -> geht, ist also geschlossen.

Es wird definitiv kein weiteres Assignfile angesprungen welches diese Datei
öffnet. Nach dem nächstem Versuch diese Settings zu speichern kommt bei rewrite
die Exception ( nicht bei FileisOpen !! ) und DANACH hab ich eine 0Kb Datei die sich
nicht löschen lässt.

Hab bei Herrn Amazon nun ne XE8 Pro gekauft. Hoffe der Umstieg wird keine
Katastrophe..

[zeras]

Vielleicht macht auch dein Virenscanner Probleme?
Du kannst ja auch mal eine kurze Zeit warten und dann nochmal versuchen.

[FarAndBeyond]

Ich würde grundsätzlich immer try..finally innerhalb von try..except benutzen...
Der Schutzblock steht ja auch bei SirRufo schon mit drin...

Delphi-Quellcode:

Function CDevice.storerSettings(name: string) : integer;
 Var 
  i: integer;
  f: file of TPSettingsFile;
  s: TSettingsFile;
 Begin
  Try 
   storeSettings := -1;
    If Not FileExists( name ) 
    Then raise EInOutError.CreateFmt( 'File %s does not exists!', [name] );
  
    If IsFileInUse( name ) 
    Then raise EInOutError.CreateFmt( 'File %s is open!', [name] );
    
   AssignFile(f, name);
    Try   
     Rewrite(f);
     s.magic := $537916;
     //...usw.
     Write(f, s);
    Finally
     Try
      Closefile(f); // oder direkt in separater, abgesicherter Prozedur... 
      storeSettings := 0;
     Except
      Info + StandardExceptionHandling.... was auch immer... 
      storeSettings := -1;
     End;
    End;
  Except
   // Standard ExceptionHandling, was auch immer man möchte... 
  End;
 End;

Ist halt immer die Frage wie detailiert braucht man ein ExceptionHandling... schließlich kann man das noch um einiges erweitern...

[Sir Rufo]

Versuch mal die Methode zu beschreiben (dokumentieren). Wenn du einen Roman dazu schreiben musst, dann machst du dort zu viel.

Und ein

Delphi-Quellcode:

try except

was die gesamte Methode umschliesst, die eine echte Arbeit erledigt, ist vom Konzept her falsch.

Die Methode vorher, die diese aufruft, legt den Namen fest. Dort hätte ich eine Möglichkeit vernünftig auf diese Exceptions zu reagieren (z.B. einen anderen Dateinamen). Also kommt das Exception-Handling dort hinein, oder man lässt die einfach hochpoppen.

[mm1256]

Ich vermute, dass das wahre Problem nicht in dieser Funktion liegt, sondern schon vorher irgendwas Dummes passiert, z.B. Speicher überschrieben. Beim "Wiederholen" tritt es dann auf. Darum würde ich erst mal mit

Code:

{$Q+,R+, D+, L+}

compilieren und dann müsste man doch was sehen?

[FarAndBeyond]

Zitat:

Versuch mal die Methode zu beschreiben (dokumentieren). Wenn du einen Roman dazu schreiben musst, dann machst du dort zu viel.

Ja, ich schätze ich mach' generell zu viel in dieser Richtung, ist ja auch nur ein Denkanstoss... Das Programm bzw. die restlichen Prozeduren kenne ich ja gar nicht.

Zitat:

Und ein try except was die gesamte Methode umschliesst, die eine echte Arbeit erledigt, ist vom Konzept her falsch.

Das würd' ich aber echt gerne noch kapieren. Ich mach' das immer so, da ich nie weis welche Programme, Treiber, Dienste zusammen laufen werden und ob diese harmonisch laufen. Wieso sollte man das nicht machen??? Komplett fühlt sich irgendwie gut an...

Zitat:

Also kommt das Exception-Handling dort hinein, oder man lässt die einfach hochpoppen.

"hochpoppen" ... Bedeutet das, ich zeige dem User die Exception an und gehe dann aus der Prozedur 'raus? Ich will ja nicht, dass die Kiste abschmiert nur weil ein Dateizugriff nicht ging.

[mm1256]

Über die Art und Weise wie man Exceptions behandelt, wirst du sicher mehrere Meinungen bekommen, und jeder ist überzeugt, er macht es richtig. Meine Meinung ist: Wenn es nichts "zu behandeln" gibt, dann musst du dem User die Exception zeigen, weil du ja selber nicht darauf reagieren kannst. Aber, wegen dem "Zeigen" schmiert noch lange kein Programm ab.

Bei Exceptions stellt sich doch immer zuerst die Frage, wer hat sie verursacht? In diesem Fall ist die Frage relativ einfach zu beantworten: Du! Denn, wenn ein Dateizugriff das erste mal funktioniert, und das zweite mal nicht, dann hast du irgendwo einen Bug produziert, und der sollte/muss weg. Wenn du dich nicht darum kümmerst, kann das unangenehme Folgen haben.

Ich hatte noch keinen Kontakt mit FreePascal oder Lazarus, aber da gibt es doch sicher auch einen Debugger. Was kommt denn dabei raus, wenn du wie von mir vorgeschlagen mit {$Q+,R+, D+, L+} compilierst?

[Sir Rufo]

Hmmm, ich weiß nicht was da "abschmiert". Im Gegenteil, dein Programm bleibt eher stabil.

Oder wie willst du hier irgendwas in den Stream schreiben, wenn du

• Keine Instanz übergeben hast
• Keinen Dateinamen übergeben hast
• Keine Datei erzeugen konntest

Diese Methode muss einfach abgebrochen werden, weil eine sinnvolle Weiterführung nicht möglich ist.

Delphi-Quellcode:

procedure DoSaveFoo( AFoo: TFoo; AFileName : string );
var
  LFooData: TBytes;
  LStream: TStream;
begin

  // Guard Block - zu 99.9% ein Programmiererfehler, wenn das kommt

  // Kein Foo, dann kann ich nichts machen => tschüssi
  if not Assigned( AFoo ) then
    raise EArgumentNilException.Create('AFoo');
  // Kein Dateiname, dann kann ich nichts machen => tschüssi
  if AFileName.IsEmpty then
    raise EArgumentNilException.Create('AFileName');

  LFooData := SerializeFoo( AFoo );
  LStream := TFileStream.Create( AFileName, fmCreate or fmShareExclusive );
  try
    LStream.WriteData( LFooData, Length( LFooData ) );
  finally
    LStream.Free;
  end;
end;

Aber die Methode vorher, die könnte etwas machen. Wenn es ein Problem mit dem FileStream gab (

Delphi-Quellcode:

EFileStreamException

= alle Exceptions von

Delphi-Quellcode:

TFileStream

ohne die normalen Exceptions die

Delphi-Quellcode:

TStream

wirft), dann wird das 9 mal mit einem neuen Dateinamen versucht. Wenn das nicht funktioniert hat, dann wird diese Exception auch weitergereicht (angezeigt).

Alle anderen Exceptions laufen einfach durch und werden direkt angezeigt.

Delphi-Quellcode:

procedure SaveFoo();
var
  LFoo: TFoo;
  LFooFileName: string;
  LRetry: Integer;
begin
  LFoo := TFoo.Create;
  try

    LRetry := 0;
    while true do
    begin
      LFooFileName := GetTempFileName();
      try
        DoSaveFoo( LFoo, LFooFileName );
        Break;
      except
        on E: EFileStreamError do
        begin
          Inc( LRetry );
          if LRetry = 10 then
            raise;
        end;
      end;
    end;

  finally
    LFoo.Free;
  end;
end;

[redox]

Die function CDevice.storeSettings(name: string) : integer; liefert statt boolean/nachvollziehber INTEGER.

Das "Hab bei Herrn Amazon nun ne XE8 Pro gekauft. Hoffe der Umstieg wird keine
Katastrophe.. " wird alle Probleme lösen!

Geld statt Hirn löst alle Probleme, denn dann kann man statt Denken das Denkenlassen bezahlen ;-)

MfG

[FarAndBeyond]

@mm1256:
Danke für die Compiler Info, kann ich vielleicht mal brauchen...

@SirRufo:
Besten Dank für das Beispiel...

Sorry Leute, ich hab' das Thema gar nicht gestartet, bin aufgrund des ExceptionHandlings auf den Zug aufgesprungen, weil mich das interessierte...
Kann schlecht testen ob das funzt, da gar nicht mein Programm bzw. Problem...

Ich bin dann mal weg... nichts für ungut...

[calibra301]

Schande über mich....
{+I} , einen Compilerschalter, aus versehen gelöscht...

Wenns nicht mehr geht das Projekt in die Ecke werfen und ein paar Tage später wieder ran.
Mann sieht seinen eigenen Blödsinn nicht..

Noch mal danke für die Hilfe, aber gegen eigene Blindheit hilft nix...

Gruss
Calli . . der schon das nächste Problem hat..