Wieso Speicheranforderung in Try...Finally ?

[stahli]

@FredFesl

So selbstbewußt hätte ich es nicht vortragen können, sehe das aber genau so.
Ansonsten müsste man (wenn man es genau machen wollte) beim Erzeugen von 10 Objekten nacheinander auch 10 verschachtelte Schutzblöcke erzeugen (für jedes Objekt einen).
Es kann ja jeder machen wie er will, aber der Sinn erschließt sich mir (in den meisten Fällen) nicht.


@WM_CLOSE+Luckie

Wenn ein Programm mit einem solch gravierenden Fehler wochenlang durchläuft, ist mit dem Ergebnis wohl ohnehin nix anzufangen.
Das gilt jedenfalls, wenn der Fehler nicht komplett bereigit wird (incl. aller Daten und Zustände).
Und diese Bereinigung kann man eigentlich nur gewährleisten, wenn man mit einem bestimmten Fehler rechnet, den man aber nicht unbedingt vermeiden kann (E/A-Funktionen).

[himitsu]

Ich sage es mal so "schau dir meinen FileSplitter (hier in der DP) mal an.
weiter siehe *1


Ja, wenn nach einem Knall (Exception) sowieso alles zu spät ist, könnte man es auch gleich sein lassen ... Windows räumt ja auf.

Aber dennoch sollte man es in einem gewissen Maße machen, denn wenn man etwas immer gleich macht, egal ob das Programm wichtig oder nutzlos ist, dann hat man a) ähnliche Programmstrukturen (Wiederverwendbarkeit) und damit auch ein leichteres Arbeiten, da man sich nur an eine Struktur halten muß, was auch das Lesen/Verstehen vereinfacht
und wenn man dann durch das viele Programmieren dieses total verinnerlicht hat, dann kann man es an wichtigen stellen nicht so schnell vergessen.



*1 Ja, auch ich schreibe schonmal Programme ganz ohne Try-Finally, denn unter gewissen Umständen ist sowas garnicht nötig, da z.B. die WinAPI an vielen Stellen mit Fehlercodes arbeitet und nicht mit Exceptions.
Wenn es dort Probleme gibt, dann werden diese nicht gleich mit einer Exception quitiert und man kann/muß diese Fehler dann anderes behanden. (knallt es dort wirklich mal mit einer Exception durch, dann ist sowieso alles zu spät und jede weitere Bemühung eher umsonst)


Mit genügend Wissen/Erfahrung kennt man gewisse Schwachstellen oder auch Ecken, wo eigentlich nie was schief laufen kann ... in soeinem Kall kann man die Fehlerbehandlung auch schonmal etwas "anpassen".

Aber im Normalfall sollte man einfach alles Schützen, wenn man weiß ja nie was mal passiert ... ganz besonders bei Codes, welche man anderen zur Verfügung stellt.
siehe http://www.delphipraxis.net/162202-s...ml#post1116391
Das Original hieß

Delphi-Quellcode:

Result := '';
Parse := TStringList.Create;
Row := TStringList.Create;
try
  Parse.Text := GetBarcodesResult;

Was eigentlich auch schon sicher genug ist. (siehe meine Erklärung dort drüben)
Aber dennoch, ein gewisser (ausreichender) Schutz wird dennoch verbaut, auch wenn einige meinen könnten "wozu ... ist doch eh umsonst?".
Denn weißt du, ob der Code nicht mal in einem wichtigen Programm verbaut würde?

[FredlFesl]

Zitat von himitsu:

und wenn man dann durch das viele Programmieren dieses total verinnerlicht hat, dann kann man es an wichtigen stellen nicht so schnell vergessen....

*1 Ja, auch ich schreibe schonmal Programme ganz ohne Try-Finally, denn unter gewissen Umständen ist sowas garnicht nötig,...
Mit genügend Wissen/Erfahrung kennt man gewisse Schwachstellen oder auch Ecken, wo eigentlich nie was schief laufen kann ...

Aber im Normalfall sollte man einfach alles Schützen, wenn man weiß ja nie was mal passiert ... ganz besonders bei Codes, welche man anderen zur Verfügung stellt.

Also wird das Try-Finally immer angegeben, obwohl wir alle wissen, das es in diesem konkreten Beispiel vielleicht überflüssig ist, aber, hey, sicher ist sicher und außerdem schauen Kinder zu und da konnen wir nicht einfach sagen das man sich manchmal nicht schützen muss.

So, wie wenn wir immer erzählen, das man die Ampel nur bei 'grün' überqueren darf, aber: -unter uns-, wenn sonst keiner da ist, WTF.

[Uwe Raabe]

Ich hätte da auch noch etwas Senf dazu: Es mag ja durchaus sein, daß zum Zeitpunkt der Programmierung das Freigeben eines Objekts auch nach einer Exception ziemlich egal ist. Das muss aber nicht für immer so sein. Ist zwar etwas konstruiert, aber man stelle sich vor, daß das Objekt eine externe Resource belegt (z.B. eine Server-Verbindung aufbaut, einen COM-Server startet oder einen Lizenzzähler hochzählt), die unter allen Umständen wieder freigegeben werden muss.

Der Punkt dabei ist, daß dieses Verhalten vielleicht erst später eingebaut wird oder womöglich erst zur Laufzeit bestimmt wird. Dann möchte man ja auch nicht alle Instanzen in allen Programmen durchgehen, ob die denn auch schön brav in ein try-finally geklammert sind.

Insofern ist ein try-finally Block etwas, daß mir womöglich meine zukünftige Arbeit erleichtert und mich vor meinen eigenen Fehlern schützt.

[samso]

Zitat von stahli:

Ansonsten müsste man (wenn man es genau machen wollte) beim Erzeugen von 10 Objekten nacheinander auch 10 verschachtelte Schutzblöcke erzeugen (für jedes Objekt einen).

Verstehe ich nicht, in dem Thread "Bitte Warning erklären" wurden doch bereits Lösungen gezeigt, wie man die Verschachtelungen vermeiden kann. Auch die Behauptung "Wenn eine Exception auftritt, kann man alle weiteren Berechnung danach vergessen" stimmt doch so pauschal nicht. Das hängt doch stark von dem Kontext ab. Programme der Kategorie 24/7 haben da sicherlich andere Ansprüche, als ein Kommandozeilentool, dass nur mal schnell für eine spezifische Aufgabe zusammen gestrickt wurde.

Bei mir ist es eigentlich eher umgekehrt. Wenn in meinen Quelltext mal ein Schutzblock fehlt, dann ist das bei einer späteren Inspektion des Quelltextes immer ein Punkt, bei dem ich dann u.U. länger nachdenke, ob das an dieser Stelle tatsächlich legitim ist. D.h. ich verwende eventuell mehr Zeit bei der Wartung eines Quelltextes, wenn der Schutzblock fehlt, als wenn ich ihn konsequent einbaue.

D.h. der Schutzbock um "b.work" in dem Eingangs genannten Beispiel ist schon deshalb sinnvoll, weil ich bei der Wartung nicht in b.work reingehen muss um zu prüfen, ob da auch wirklich keine Exception auftreten kann.

Impliziert das Wort "Schutzblock" nicht schon, dass es sich um einen Security-Layer handelt? Und nein, ich kann mir keinen anderen sinnvollen Einsatz von Try-finally-Blöcken vorstellen, als genau diesen. Letztendlich ist es also die Frage, will ich auf Nummer sicher gehen, oder glaube ich, dass ich und alle anderen Verkehrsteilnehmer so gut sind, das niemals ein Unfall passieren kann (bzw. die Konsequenzen eines Unfalls sind mir einfach egal). Das muss jeder für sich entscheiden.