Forum: Object-Pascal / Delphi-Language
by stahli,
20. Mai 2011
:thumb: Genau so sehe ich das auch - aber eben auch für eine gesamte Methode. Wenn ich diese ausgiebig getestet habe und sicher bin, dass alles korrekt funktioniert (außer, wenn vielleicht der Hauptspeicher defekt ist o.ä.) dann kann ich auf solche Absicherungen auch verzichten, die eben aus meiner Sicht auch nur einen begrenzten Nutzen haben. Das Programm funktioniert ohnehin nicht mehr korrekt...
Forum: Object-Pascal / Delphi-Language
by stahli,
20. Mai 2011
Es käme mir dabei eben nicht darauf an, wenn es "knallt". Gegeben sei eine tadellos funktionierende Funktion.
Deine 3 Punkte bearbeiten jede Menge Fallunterscheidungen, komplexe Verschachtelungen, Funktionsaufrufe usw.
An unterschiedlichen Stellen kann Exit aufgerufen werden und final noch etwas erledigt werden.
Das Ganze hat NICHTS mit Versuchen oder Fehlern zu tun. Es gibt diverse Abläufe...
Forum: Object-Pascal / Delphi-Language
by stahli,
19. Mai 2011
Ohne den Try-Block in der übergeordneten Methode hätte es SOFORT eine schöne Fehlermeldung in der Funktion gegeben.
Durch den Try-Block wurde die unterdrückt. Ich habe den Fehler ja letztlich gefunden aber ich bin immer noch der Meinung, dass try nur bei "ERWARTETEN FEHLERN" Sinn macht (z.B. E/A-Fehler), auf die dann reagiert werden muss.
Was nutzt es mir, wenn 2 Objekte freigegeben werden,...
Forum: Object-Pascal / Delphi-Language
by stahli,
19. Mai 2011
@Omata
Sofern nur ein Try-Block existiert stimmt das (habe ich ja in meinem Projekt jetzt auch so genutzt).
Aber die Struktur ist unschön, sofern in FuncA ein Fehler auftritt. Dieser ist schwerer zu finden, als wenn es keinen Try-Block gäbe.
begin
try
FuncA;
FuncB;
// hier kommt alles rein
finally
Forum: Object-Pascal / Delphi-Language
by stahli,
19. Mai 2011
Ich habe mal ein Testprojekt angehängt.
An den try-Blöcken stört mich die schlechte Debugbarkeit. Gerade habe ich einen Fehler gefunden, der in einer aufgerufenen Funktion auftrat. Durch den sch... try-Block war der schlechter lokalisierbar.
Ich mag die Dinger nicht und halte sie für wesentlich überschätzt.
Wenn man sie konsequent nutzen will, müsste man quasi jeden Befehl in einen try-Block...
Forum: Object-Pascal / Delphi-Language
by stahli,
30. Apr 2011
Sehe ich auch so. Der Code wird u.U. einfach kürzer und übersichtlicher.
Zumal man mit Exit(Value) in Funktionen auch gleich einen Result-Wert zuweisen kann.
Forum: Object-Pascal / Delphi-Language
by stahli,
30. Apr 2011
Ok, das (finally und DANN exit) hört sich sehr gut an. Ich schaue mir das wie gesagt noch genau an.
Danke!
PS: In meinem Beispiel ist natürlich klar, dass O vor dem Exit freizugeben wäre. Da war ich etwas zu hektisch. Sorry.
Forum: Object-Pascal / Delphi-Language
by stahli,
30. Apr 2011
Na ja, grundsätzlich sind mir die Fehlerbehandlungen schon klar.
Nur, wenn es irgendwo knallt, ist es m.E. zweitrangig, ein erzeugtes Objekt auch wieder frei zu geben.
Jedenfalls nicht, wenn nicht innerhalb der Fehlerbehandlung selbst wieder ein konstistenter Projektzustand hergestellt wird.
Wenn Exit in einem Try-Block in finally springt, ist das schon mal eine Lösung, aber nicht wirklich...
Forum: Object-Pascal / Delphi-Language
by stahli,
30. Apr 2011
Ok danke. Klar glaube ich Euch das, aber ich wusste das nicht.
Ich arbeite selten mit try-Blöcken.
Ich hatte beim programmieren lernen gelesen, dass man try-Blöcke (nur) verwendet, um Fehlermeldungen bei erwarteten (und zu tolerierenden) Fehlern zu unterdrücken.
Also z.B. bei I/O-Funktionen.
Das steckt halt so drin. Aber ich werde mir das noch mal genauer ansehen...
Danke!
Forum: Object-Pascal / Delphi-Language
by stahli,
30. Apr 2011
Ich würde mir folgende Delphi-Syntax wünschen:
function MyFunc(var Counter: Integer): Real;
var
O: TMyObject;
begin
O := TMyObject.Create;
O.MachWas(Counter);
if (O.Dies) then
Exit(Random)
