Initialisierung von result wird wegoptimiert

[Uwe Raabe]

Zitat:

Zitat von idefix2 (Beitrag 1380732)

Dann führt clicked:=true (wie jeder andere Zugriffsversuch auf das Objekt) zu einer Exception, die man ganz einfach ignorieren kann, weil einen Klick auf ein Element, das ohnehin schon zum Löschen markiert war, braucht man nicht mehr zu berücksichtigen, und andere Exceptions sind an dieser Stelle absolut unplausibel.

Dann würde ich auch gezielt auf

Delphi-Quellcode:

EAccessViolation

prüfen, aber eben nicht jede Exception abfangen. Wie du schon sagst, kann man nur die Exceptions behandeln, die man vorhersehen kann. Alle anderen sollen dann aber auch irgendwie gemeldet werden - insbesondere dann, wenn sie absolut unplausibel sind, denn sonst würden sie ja zur ersten Gruppe gehören.

[Blup]

EAccessViolation bedeuted in jedem Fall das der Programmierer irgend etwas falsch macht. Man kann sich nicht darauf verlassen das der Zugriff auf bereits freigegebene Objekte in jeder Situation diese Exception auslöst. Im schlimmsten Fall hat der Speichermanager den Speicherbereich bereits für ein neues Objekt bereitgestellt, das dann an dieser Stelle unvorhersehbar verändert oder gar freigegeben wird. Das führt zu weiteren Fehlern in anderen Programmteilen, die niemand finden oder korrigieren kann.

[gerdich]

Das wäre aber ein sehr hässliches Verhalten von Delphi, wenn bei einer Exception in einem try...finally-Konstrukt der Rückgabewert der Funktion verloren ginge. Einen vernünftigen Grund dafür gibt es nicht. Die übrigen Werte gehen ja auch nicht verloren, sonst könnte man den finally-Block gar nicht sinnvoll ausführen. In der Dokumentation steht das auch nicht.

Das bedeutet, dass man bei jeder unbekannten Funktion überprüfen müsste, ob sie überhaupt einen sinnvollen Wert zurückgibt. Sie könnte ja ein try...finally-Konstrukt enthalten. Das würde die ganze algorithmische Sicherheit auf den Haufen werfen, wäre also ein Totalschaden.

Nein. Es gibt keine Ausrede für den Bug, dass Delphi den Rückgabewerte einer Funktion wegoptimiert bei einem try...finally-Konstrukt.

[Uwe Raabe]

Zitat:

Zitat von gerdich (Beitrag 1405892)

Das bedeutet, dass man bei jeder unbekannten Funktion überprüfen müsste, ob sie überhaupt einen sinnvollen Wert zurückgibt. Sie könnte ja ein try...finally-Konstrukt enthalten.

Du hast offensichtlich meine Antwort im #2 nicht gelesen:

Zitat:

Zitat von Uwe Raabe (Beitrag 1380603)

Da die Exception durch das finally ja nicht abgefangen wird gelangt der Result-Wert auch nicht zum Aufrufer zurück. Insofern wird bei einer Exception der Result-Wert auch nie benutzt.

Du musst also nicht überprüfen, ob die Funktion einen sinnvollen Wert zurückgibt, da diese Überprüfung eh nicht ausgeführt würde wenn eine Exception auftritt. Das ist übrigens unabhängig davon, ob die Funktion einen try-finally-Block enthält oder nicht.

Probier es doch einfach mal aus.

[gerdich]

Ich habe nicht daran gedacht, dass das finally-Konstrukt die Exception im aufrufenden Programm nicht verhindert.

[gerdich]

Das bedeutet aber eigentlich, dass man eine Funktion mit try...finally-Konstruct in der aufrufenden Funktion/Prozedur immer in einem try...except-Konstrukt abfangen muss, wenn man verhindern will, dass das Programm sich unvorhergesehen benimmt. (Falls die aufgerufene Funktion dies nicht selber schon tut.)

[Uwe Raabe]

Zitat:

Zitat von gerdich (Beitrag 1405899)

Das bedeutet aber eigentlich, dass man eine Funktion mit try...finally-Konstruct in der aufrufenden Funktion/Prozedur immer in einem try...except-Konstrukt abfangen muss, wenn man verhindern will, dass das Programm sich unvorhergesehen benimmt. (Falls die aufgerufene Funktion dies nicht selber schon tut.)

Genauer gesagt gilt das für jede Funktion, die eine Exception werfen könnte. Wobei man das Exception-Handling auch weiter oben im Callstack ansiedeln kann, je nachdem, wo es sinnvoll ist.