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