Fehler bei Verwendung von try/except

[haentschman]

Hallöle...8-)

Ich habe einen Exception Block, falls die Datei nicht geöffnet werden kann. (Bild1 - Fehler den ich erwarte)

Nach der Fortsetzung in der IDE bekomme ich einen Fehler den ich nicht kenne...:gruebel:
Könnte mir jemand die Fehlermeldung erklären? (Bild2)

Ich komme in den Exception Block noch nicht mal rein. :shock: (Bild3) Mit Ok komme ich in die CPU Ansicht! :roll:

Danke...

[Uwe Raabe]

Was ist den List?

[just beginner]

Schon 12.2 Patch1 eingespielt?


Publicly Reported Issues Addressed by this Patch
This patch addresses the following public reports on Quality Portal (https://qp.embarcadero.com/):

RSS-698 Try catch finally bug under win64x

[haentschman]

Hallo...

Zitat:

Was ist den List?

TStringList

Zitat:

Schon 12.2 Patch1 eingespielt?

ich bin noch auf 12.1

PS: das ist nicht das erste try/exept im Programm :wink:

[PaPaNi]

Ist der List überhaupt erstellt?

[himitsu]

Ist da eine DLL mit im Spiel?

Dein Except-Block, bzw. das ON ist auf Exception-Typ und Nachfahren eingeschränkt,
und wenn es was anderes ist, wobei auch der Exception-Typ einer anderen DLL was Anderes ist, wenn (normal) die TypeInfos/RTTI nicht durch das RTL-Runtimepackage gleichgeschaltet sind.

[haentschman]

Danke...

Zitat:

Ist der List überhaupt erstellt?

Ja. :wink:

Zitat:

Ist da eine DLL mit im Spiel?

In diesen 20 Codezeilen nicht.

Ich habe diese Prüfung auf "Keinen Zugriff" erst jetzt um das List.LoadFromFile herumgebaut...damit nicht der MadExcept 1 Mal im Jahr an dieser Stelle aufpoppt. :zwinker:
Original:

Delphi-Quellcode:

if FDialog.Execute(Parent.Handle) then
begin
  FPreferences.PreferencesCommon.ImportCsvEMCOTFolder := ExtractFilePath(FDialog.FileName);
  FPreferences.SavePreferences;
  List.LoadFromFile(FDialog.FileName);
  FileNameComplete := FDialog.FileName;

  // Prüfung ob schon eingelesen
  FileName := ExtractFileName(FileNameComplete);
  FileNameBackup := FileName;
  ... 
  // ca. 15 Zeilen weiter in der gleichen "procedure" ohne Fehler
      ...
      except
        on E: Exception do
        begin
          if Assigned(FOnEndImport) then
          begin
            FOnEndImport(Self);
          end;

          DMZU.Database.TransactionRollback;

          if Assigned(FOnImportError) then
          begin
            Error := TKTEError.Create;
            try
              Error.ErrorType := etMisc;
              Error.ErrorStrings.Text := E.Message;
              FOnImportError(Self, Error);
            finally
              Error.Free;
            end;
          end;
        end;
      end;

Wer kennt diesen Fehler? :?


Kommando zurück! :roll:

Ein 2. Delphi Neustart hat es gebracht. :evil: Jetzt wird auch der Block ausgeführt und die Fehlermeldung in der Oberfläche angezeigt. Ich hasse es. :evil:

Danke fürs Zuhören...:wink:

[shebang]

Zitat:

Zitat von haentschman (Beitrag 1542525)

Wer kennt diesen Fehler? :?

Er hat auf jeden Fall etwas mit Delphi zu tun, wenn auch nicht unbedingt mit der Anwendung, die du gerade debuggst, siehe z.B. hier und hier. Ist die Andendung, die die Datei blockiert auch mit Delphi geschrieben?

[haentschman]

Danke...ist erledigt. :wink: War wie du schon erwähnt hast...Delphi! :roll:

[Kas Ob.]

@haentschman ,

With Delphi compiler changes, it really could be a bug, i don't have the latest Delphi IDEs so i can't say, but here few thoughts on your code and your approach from what i know :

1) Remove the need for the nested try..except around try..finally because in theory finally should start the local procedure and it should end it, so it could be a bug, but what ever the case is, your code is calling FOnImportError , why ?
You could refactor this into clearer code, by introducing DoError or DoImportError with any needed parameters, and form there you can put creating your custom error and free it with try..finally block.
2) the code when exception being raised is calling FOnEndImport before FOnImportError, i think this is wrong approach, just in case you needed to check the detail of the import from the Error handler but being End called before is a risk of confusing the data and logic flow.
3) Yes as mentioned above and from David answer on SO, 0EEDFADE is Delphi specific exception, but being captured by the OS and the OS didn't forwarded to the application for many reasons, among them the stack is being corrupted or the exception structure has been malformed by wrong parameter(s) in the SEH record, this easily could be a bug in generated code where finally block invoked and did overwrite the the except block, but also could be EurekaLog or MadShi hooked the handled exception and caused this corruption.

in all cases i see a simple and small refactor could easily remove this in full and solve your code issue.