Initialisierung von result wird wegoptimiert

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

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

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.