Fehler bei Verwendung von try/except

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

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

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

Danke fürs Zuhören...

[shebang]

Zitat von haentschman:

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. War wie du schon erwähnt hast...Delphi!

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