Rewrite(f) findet File nicht...

[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 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 (EFileStreamException = alle Exceptions von TFileStream ohne die normalen Exceptions die 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