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

Delphi-Quellcode:

if Assigned(ComboBoxListe)

prüfen.

[Sherlock]

Pauschale Antwort, die immer geht: Liegt am

Delphi-Quellcode:

with

.

[Lemmy]

Zitat:

Zitat von Sherlock (Beitrag 1540062)

Pauschale Antwort, die immer geht: Liegt am

Delphi-Quellcode:

with

.

Da es sonst keine Möglichkeit gibt: :thumb:

[Sinspin]

Zitat:

Zitat von Sherlock (Beitrag 1540062)

Pauschale Antwort, die immer geht: Liegt am

Delphi-Quellcode:

with

.

:thumb:

Wer

Delphi-Quellcode:

with

verwendet hat nur exceptions verdient.

[DeddyH]

Delphi-Quellcode:

with Exceptions do live;

:mrgreen:

[dummzeuch]

Hey Leute,

die eigentlich Frage ist doch dies hier:

Zitat:

Zitat von looseleaf (Beitrag 1540059)

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?

[looseleaf]

Erstmal freu ich mich über so rege Beteiligung. Und ja, wer ein With verwendet, gehört zum ANSI-C-Programmieren abkommandiert :)

Es ist eine Zugriffsverletzung mit einem Pointer ungleich 000000xx, also irgendeinem wild gewordenen Speicherbereich, würd ich mal interpretieren. Ich hab mehrere Stackdumps, und schau mir die morgenin deR Arbeit nochmal an.

wenn die ComboBox nil oder freigegeben wäre, dann könnte hier schon eine Exception auftauchen, weil im With ja gleich deren Items verwendet wird.
Aber mir ist nicht klar - wie dummzeuch auch nochmal präzisiert - wieso das Exception-Handling hier überhaupt nicht greift.

Ich schließe nicht aus, dass irgendwo im Programmverlauf via Application.ProcessMessages das Schließen des Forms ausgelöst werden könnte. Aber dann müsste die komplette Methode schon im Nirvana verschwinden (was würde hier wirklich passieren?), oder?

Liebe Grüße
Stefan

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1540068)

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:

Delphi-Quellcode:

function TFormWarten.IstTagesListe: Boolean;

: hat die Funktion einen Übergabeparameter? Oder gibt es da eine überladene Version?
Ich frage deswegen, weil später

Delphi-Quellcode:

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.

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

Zitat von paule32.jk (Beitrag 1540079)

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.