Try - except - finally

[bernau]

Zitat von Furtbichler:

Wenn Du es 'falsch' angehst: Ja.

Wieder was gelernt

[idefix2]

Welchen Sinn es haben soll und inwieweit es "richtiger" sein soll, die finalen Aufräumarbeiten und die Fehlerbehandlung in zwei getrennte Prozeduren zu stecken, wobei eine die andere aufruft, erschliesst sich mir überhaupt nicht (ausser, mit dem Auftraggeber ist ein Zeilenhonorar vereinbart ). Das Programm wird dadurch weder besser lesbar noch übersichtlicher, eher im Gegenteil.

[Daniel]

Oftmals wird eine Code-Stelle, an der eine Exception auftritt, gar nicht in der Lage sein, eine Entscheidung zu treffen, wie mit der Situation umgegangen werden soll. In diesem Fall ist sie geradezu gezwungen, die Exception nach draußen zu reichen.

[Der schöne Günther]

Als kleiner Einwurf der hier garantiert niemanden wirklich weiterbringt: In den ersten Tagen (Wochen?) Delphi habe ich mich auch immer wieder daran gerieben, kein try-except-finally zu haben. Um ehrlich zu sein, gefällt mir der Delphi-Weg mittlerweile besser, es ist einfach nur eine Gewöhnungssache.

Mir ist im Nachhinein auch aufgefallen dass wenn mich das rein optisch (von der Einrückung) her anfing zu stören, meine Methoden eh viel zu lang waren.

PS: Wann kommt endlich ARC auf den Desktop? Damit spart man sich wohl endlich 95% aller

Delphi-Quellcode:

Referenz := TObject.Create();
try
  [...]
finally
  Referenz.Destroy();
end;

sparen

[silver-moon-2000]

Zitat von Der schöne Günther:

Delphi-Quellcode:

Referenz := TObject.Create();
try
  [...]
finally
  Referenz.Destroy();
end;

sparen

Jetzt mal blöd gefragt,
fliegt Dir das nicht doch noch um die Ohren, wenn die Erzeugung von Referenz fehlschlägt?
Sollte man nicht besser Referenz.Free aufrufen,
denn das prüft doch noch auf <> nil , bevor es destroy aufruft?
Oder denke ich falsch?

[mkinzler]

Ja, .Destroy() sollte man nie direkt aufrufen.

[Furtbichler]

Zitat von idefix2:

Welchen Sinn es haben soll und inwieweit es "richtiger" sein soll, die finalen Aufräumarbeiten und die Fehlerbehandlung in zwei getrennte Prozeduren zu stecken, wobei eine die andere aufruft, erschliesst sich mir überhaupt nicht (ausser, mit dem Auftraggeber ist ein Zeilenhonorar vereinbart ).

Jede Methode soll genau eine Sache machen. Die Beschreibung der Methode sollte kein 'und' enthalten. Wenn doch, sollte man 2x hinschauen, ob man die Methode nicht aufsplitten kann. Kommentare (außer Rechtshinweise, Beschreibung von speziellen Algorithmen und vielleicht Klassenbeschreibungen) sind überflüssig, wenn man seinen Code so schreibt, das er -vorgelesen- genau das beschreibt, was er macht. Und das gelingt nur, wenn man die Methoden so aufdröselt, das sich die Beschreibung einer Methode in ihrem Namen widerspiegelt und sie keine Seiteneffekte hat. Für meine Begriffe ist das die einzige Möglichkeit, Programme zu schreiben, die auch für andere schnell begreifbar sind.

Du kannst natürlich auch alles in eine Methode packen, klar. Das mag bei einem einzeiligen Aufruf (und den einfachen Beispielen hier) noch funktionieren, aber das wird schnell unübersichtlich, wenn Aufräumarbeiten, Fehlerbehandlung usw komplexer werden. Es ist einfacher, sich an dieses oder ein ähnliches Pattern zu halten. Du kannst das natürlich sein lassen und alles in eine Methode packen, ganz wie es Dir gefällt.

[Der schöne Günther]

Zitat von silver-moon-2000:

Zitat von Der schöne Günther:

Delphi-Quellcode:

Referenz := TObject.Create();
try
  [...]
finally
  Referenz.Destroy();
end;

sparen

Jetzt mal blöd gefragt,
fliegt Dir das nicht doch noch um die Ohren, wenn die Erzeugung von Referenz fehlschlägt?
Sollte man nicht besser Referenz.Free aufrufen,
denn das prüft doch noch auf <> nil , bevor es destroy aufruft?
Oder denke ich falsch?

Ich sehe hier kein Problem. Wenn ich in den try-Block reinkomme, war der Konstruktor erfolgreich und es gibt eine gültige Referenz.

Fliegt der Konstruktor bereits raus, wird der try-Block erst garnicht ausgeführt (aber der Destruktor des Objekts aufgerufen).

[Furtbichler]

Alles richtig, Günni.

[Aviator]

Zitat von Furtbichler:

Zitat von Bernhard Geyer:

Da wird man wohl diese Sprachunschönheit akzeptieren müssen und doppelt aufbauen

Das ist Geschmackssache. In C# gehts auch nicht und das ist auch OK so (imho).

Ich muss es einfach auch nochmal sagen. Natürlich gibt es in C# ein Try-Catch-Finally Block

Sieht dann in etwa so aus:

Code:

try
{
    DoSomething();
}
catch (InvalidOperationException ex)  // Oder was auch immer für eine Exception
{
    HandleException();
}
catch (Exception ex)  // Noch andere Exceptions abfangen
{
    HandleAnotherException();
}
finally
{
    MakeTheFinalStep();
}