try except und trotzdem eine Exception

[looseleaf]

Liebe Gemeinde,

wir haben folgenden Code als Methode eines Forms:

Code:

function TFormWarten.IstTagesListe: Boolean;
begin
try
  Result := false;
  With ComboBoxListe, Items do
    if (ItemIndex>=0) and (ItemIndex<Count) then
      Result := IstTagesListe(Integer(Objects[ItemIndex]));
except
  Result := false;
end;
end;

In manchen Situationen gibt es eine Zugriffsverletzung in der Zeile mit dem With bzw. eines danach mit ItemIndex (also nicht bei dem Cast von Objects auf Integer). Was mich aber fasziniert ist die Tatsache, dass die Exception durchgeht und im OnException-Handler der Applikation landet. Wenn ich manuell ein
rauise Excpetion.Create('Test');
reinschreibe, passiert das nicht, die Exception wird immer schön brav mit dem except-Handler abgefangen.

Kann mir das wer erklären?

Danke
Stefan

[himitsu]

"Zugriffsverletzung bei Adresse $000000xx" ?

nil-Pointer

oder einfach ein ungültiger Zeiger,


also das Self, bzw. die Objektvarible "ooo" draußen, vom ooo.IstTagesListe




Da der Code hier eigentlich keinen Fehler verursachen kann,
auch wenn ooo oder ComboBoxListe nil oder ungültig wären,
ist auch das Try-Except nicht wirklich sinnvoll.

nil läßt sich via if Assigned(ComboBoxListe) prüfen.

[Sherlock]

Pauschale Antwort, die immer geht: Liegt am with .

[Lemmy]

Zitat von Sherlock:

Pauschale Antwort, die immer geht: Liegt am with .

Da es sonst keine Möglichkeit gibt:

[Sinspin]

Zitat von Sherlock:

Pauschale Antwort, die immer geht: Liegt am with .

Wer with verwendet hat nur exceptions verdient.

[DeddyH]

with Exceptions do live;

[dummzeuch]

Hey Leute,

die eigentlich Frage ist doch dies hier:

Zitat von looseleaf:

Was mich aber fasziniert ist die Tatsache, dass die Exception durchgeht und im OnException-Handler der Applikation landet. Wenn ich manuell ein
raise Excpetion.Create('Test');
reinschreibe, passiert das nicht, die Exception wird immer schön brav mit dem except-Handler abgefangen.

Kann mir das wer erklären?

Darauf ist noch keiner eingegangen.

Ich kann es auch nicht erklären. Wenn im Exception-Handler mehr als Result := False stände, könnte dort auch noch eine Exception auftreten. Aber das ist ja nicht der Fall.

Vielleicht wird durch den fehlerhaften Code er Stack so kaputt gemacht, dass auch der Exception-Handler nicht mehr funktioniert?

[himitsu]

Zitat von dummzeuch:

Wenn im Exception-Handler mehr als Result := False stände, könnte dort auch noch eine Exception auftreten. Aber das ist ja nicht der Fall.

Vielleicht wird durch den fehlerhaften Code er Stack so kaputt gemacht, dass auch der Exception-Handler nicht mehr funktioniert?

Jupp, per se würde das letzte Result:= einfach nur direkt ins EAX schreiben.
Wegen dem Try-Except und da es weil mehrere Zuweisungen, auch in der in Schleife, wird dafür eine lokale Temp-Variable auf dem Stack erstellt,
welche dann am Ende ins EAX AL kopiert wird.

Wenn, dann müste der Stack schon komplett im Arsch sein
und wenn er das wäre, dann wäre eh alles sinnlos und man könnte sich die Fehlerbehandlung sparen, da dann die Anwenung sowieso nur noch abrauchen kann/sollte.


Fazit, da der Code selbst keine Fehler hat:
* Self, bzw. die externe Objektvariable ist nil oder komplett im Arsch (Variable nicht initialisiert)
* oder ComboBoxListe ist nil oder komplett im Arsch (weil ratet mal warum)
* und Dank dem With kann man auch den Debugger vergessen, weil er deswegen Vieles nicht anzeigen kann

[ULIK]

Mal eine ganz dumme Frage:

function TFormWarten.IstTagesListe: Boolean; : hat die Funktion einen Übergabeparameter? Oder gibt es da eine überladene Version?
Ich frage deswegen, weil später Result := IstTagesListe(Integer(Objects[ItemIndex])); verwendet wird, also in die Funktion ein Integer übergeben wird. Wenn es nur diese eine Funktion gibt, dann frag ich mich, wie die überhaupt mal True zurückgeben kann? Sprich kann es ein, daß sich die Funktion einfach rekursiv aufruft, bis der Stack voll ist und dann ein rein zufälliges Ergebnis geliefert wird?
Oder ist die intern aufgerufene IstTagesListe eine Methode von ComboBoxListe?

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