Initialisierung von result wird wegoptimiert

[Uwe Raabe]

Zitat von idefix2:

Ich finde das Schachteln von zwei Try Blöcken in so einem Fall sehr unschön, und auch unnötig.
Try ... except ... end - und gleich danach ein free. Wenn man im Except Block keine Bocksprünge treibt, die ihrerseits wieder zu einer Exception führen können (und das sollte man ohnedies tunlichst vermeiden), wird auf diese Art das free auch ohne zweiten try-Block zuverlässig ausgeführt.

Häufig wird aber im except-Block zwar die Exception behandelt, aber trotzdem ein erneutes raise ausgeführt. In dem Fall würde das Free ohne den finally-Block dann nicht aufgerufen. Es ist einfach guter Stil, wenn man eine Resource über ein try-finally schützt. Die Behandlung bestimmter Exceptions (einen Blanko-Except-Block ohne re-raise würde ich niemals zulassen) ist davon völlig unabhängig.

[idefix2]

Zitat von Uwe Raabe:

Häufig wird aber im except-Block zwar die Exception behandelt, aber trotzdem ein erneutes raise ausgeführt. In dem Fall würde das Free ohne den finally-Block dann nicht aufgerufen.

Wenn im Except-Block ein raise ausgeführt wird, geht das so natürlich nicht.

Zitat:

hier wird das Objekt aus Versehen freigegeben

Ich weiß nicht recht, ob man jeden noch exotischen Programmfehler unbedingt mit einem try-Except absichern muss. Für den Benutzer ist es letztlich ziemlich egal, ob er eine System Exception angezeigt bekommt oder eine Exception, die du selbst ge-raised hast. Exception Handling hat meines Erachtens überhaupt nur da einen Sinn, wo man die Fehlerbedingung wirklich auf vernünftige Weise "handeln" kann. Und Programme sollte man so weit wie möglich austesten, um Exceptions zu vermeiden. Letztens ist es doch so, dass man via Exceptions nur die Situationen in den Griff bekommen kann, wo man bestimmte Fehlertypen voraussieht. Ist das nicht der Fall, dann bleibt das Exception Handling reine Kosmetik.

[idefix2]

Zitat von Uwe Raabe:

einen Blanko-Except-Block ohne re-raise würde ich niemals zulassen

Im Allgemeinen hast du recht, aber auch da gibt es Ausnahmen, ist mir letztens erst eine untergekommen:
In einem Computerspiel soll auf einen Klick auf Objekte reagiert werden. Um eine zuverlässige Response des Programms auf Mausklicks sicherzustellen, setzt die Onclick Routine nur eine boolean Variable clicked und kehrt sofort zurück, während eine timergesteuerte Routine die Objekte durchgeht und auf die Klicks dann wirklich reagiert. Eine mögliche Reaktion auf so einen Mausklick kann aber sein, das das Objekt als Ganzes gelöscht wird. Wenn der Spieler zweimal rasch hintereinander ein Objekt anklickt, dann kann es in extrem seltenen Fällen passieren, dass unmittelbar nach dem zweiten Start des Onclick die Timer-Routine dazwischen fährt und dem Onclick sein Objekt "unter den Füssen wegzieht", indem es das Objekt löscht. 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.

[Uwe Raabe]

Zitat von idefix2:

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 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 von gerdich:

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 von Uwe Raabe:

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.