try except und trotzdem eine Exception

[Kas Ob.]

Hi,

I think i do understand the question now, and yes there is cases where try..except will not be triggered or will looks its being skipped, so

1) Why not share the exact information of that you keep calling exception, what is the message you got ? what is its code ?
this "It's an access violation with a pointer not equal to 000000xx, so some kind of memory area gone wild, is how I would interpret it. " is not helpful at all, stack will be very helpful also.
2) What is this IstTagesListe and how it is declared and if possible share its code and any relevant code to it.
3) What does Objects have ? and why you are not checking for assigned before using it "Assigned(Objects[ItemIndex])"

4) Once you mentioned Application.ProcessMessages i have to point that this is the worse to use, anyone use Application.ProcessMessages should suffer from low quality software, software that work most the time by simple luck. (sorry can't help not repeat this enough)

5) From my understanding this happen on closing the application or closing one form, right ? or i didn't understand the subject.

Some cases where try..except is skipped :
1) the SEH is corrupted, in other words either malformed from wrong and broken compiler or the stack had been corrupted (overwritten) or simply lost position by wrong calling convention.
2) once Application.ProcessMessages is there, (again will point this) then most bets are off, see, does IstTagesListe leads to Application.ProcessMessages or we are here from one of these recursive caused by ProcessMessages, as Application.ProcessMessages will break the VCL singlethreaded and unified design, example you are accessing Objects or for the sake of simplicity lets say you are accessing a line in TListBox, reading one item is in fact as message where an API will return it, but is it a dedicated API always ?!!
in many cases these are Messages called by SendMessage and these messages will be land on the (WNDPROC callback function) https://learn.microsoft.com/en-us/wi...inuser-wndproc , which must be in your application designed and running fine by the VCL, now combine these the with ProcessMessages the application is already finishing and free its forms and WNDPROC, yet they are there in code with corrupted data in memory.
Without Application.ProcessMessages any discrepancy in logic will be caught when you are developing, so calling or entering a code that belongs to a closed and freed form will raise an exception in place, and similar situations will noticed when you are developing, not depending on the content of some component, speed of the CPU, a user clikcing to fast ......

Now back to skipped try..except, Windows messages usually doesn't raise an exception, in fact almost never but there is rare cases, and this one is NOT of them, this means SendMessage (the API) does have its SEH trap (same as try..except in Delphi/Pascal) and when that message had to go to WNDPROC and raise an exception, the trap is within SendMessage, thare will the exception will be raised, so unless SendMessage re-raise it again, your own try..except around the hidden (by VCL design) SendMessage will not trap the exception and will not receive the execution.
When an exception is caught by inside an API, and this API caught the exception from your own code through callback, then what ? will it raise again or stick to the documentation to return a result, even a failure, but what about the exception ? yes it will try to pass it to application OnException or eat it in place skipping default VCL/RTL manner, hence your skipped try..except

Here a little more simplified scenario, keep in mind that all VCL application run by Application.ProcessMessages from your own code and it does have try..except or close enough.. anyway
1) Application.ProcessMessages // application running
2) Button clicked , and it invoke long process so wrongly designed will call Application.ProcessMessages
3) Application.ProcessMessages // again
4) Some other event or action in your application raising an exception within an API !
5) API within the OS caught/trapped the raised exception, either within your code or within itself, there is no guarantee how it will behave, will it unwind to (3) {or even to (1) this can happen too in rare cases} !!! because it can, or simply will re-raise and allow (4) to be triggered in case there is SEH trap (try..except).
In your case (4) had been skipped, or may be not skipped but you showed us not the complete code, your except..end; has only "Result := false;" , if there is different code that might raise an exception then it will also behave like (4) skipped, do you have more code in "except..end;" like logging and you tried to access the same object that raised the exception in the first place ???!! it could happen i saw many do it like this.

(i can keep on drawing imaginary scenarios but what is the point from listing scenarios and wasting everyone time? )


Anyway, there are many moving parts and to help you in such case you need to provide clean and clear picture of the code and the exception, with many moving parts, the more details the less guessing and less shooting darts in the dark.

Hope that helps, and sorry for the language.

[paule32.jk]

ich würde sagen: da fehlt eine .Create
weil

Delphi-Quellcode:

type
  TFoo = class;
procedure fufu;
var
  foo: TFoo;
begin
  foo := TFoo('ein parameter', 'zwei parameter');
end;

was anderes ist, als:

Delphi-Quellcode:

type
  TFoo = class;
procedure fufu;
var
  foo: TFoo;
begin
  foo := TFoo.Create('ein parameter', 'zwei parameter');
end;

aber beide Versionen vom Compiler übersetzt werden.

[DeddyH]

Zitat von paule32.jk:

aber beide Versionen vom Compiler übersetzt werden.

Das halte ich für ein Gerücht. Die erste Version könnte maximal ein Typecast sein, dann kann man aber keine 2 Werte innerhalb der Klammern angeben.

[paule32.jk]

- das mit den zwei Parametern war doch nur ein Beispiel.
- ich kenne die Struktur des OP nicht.
- in meinen Anfangsphasen mit Delphi hatte ich auch mit Schwierigkeiten, wie ich sie aufgeführt habe.