Wie mit dem Fehler in einer Klasse umgehen?

[Der schöne Günther]

Zitat:

Zitat von Sir Rufo (Beitrag 1297558)

Das ist halt wie mit der Erziehung von Hunden:

Die Bestrafung muss konsequent und sofort erfolgen, ansonsten stiftet man nur Verwirrung.

Ich hatte vergessen die Wurst wieder in den Kühlschrank zu tun. Als ich eben nach dem Hund geschaut habe hatte er die Wurst schon vertilgt. Ich tat so als hätte ich es nicht gesehen und er musste mit vollem Bauch mitkommen joggen.
Könnte man sagen, ich habe eben diese Property nicht abgefragt und ein eigentlich kaputtes Objekt mit herumgeschleppt?

[DeddyH]

Könnte man, immerhin hätte eine EDogPuking-Exception auftreten können :)

[bernau]

Zitat:

Zitat von Der schöne Günther (Beitrag 1297553)

Aber was hat man denn davon? Einen Haufen "kaputter" Objekte bei denen man dann in einem String nachschauen kann was da schief gelaufen ist?

Na ja. Popov hat folgendes geschrieben.

Zitat:

Wenn ich ein Objekt erstelle, dann vermutlich 1000 auf einmal. Natürlich will ich keine 1000 Fehlermeldungen. Gibt es eine typische Art wie Fehler vermerkt werden, so dass ich bei der Schleife es zuerst prüfen kann. Oder macht man das später im Code?

Genaues weis man nicht. Nur daß er keine 1000 Fehlermeldungen haben möchte, aber trotzdem möchte er irgendwo die Fehler vermerken. Warum nicht im Objekt?

[bernau]

Zitat:

Zitat von Sir Rufo (Beitrag 1297554)

@bernau Mit diesem Konzept wünsche ich viel Glück bei der Fehlersuche ... denn das wirst du brauchen ;)

Popov hatte nicht geschrieben, daß er den Durchlauf komplett abbrechen möchte, wenn bei einem Objekt etwas schief geht. Kann ja sein, daß er mit den "guten" Objekten arbeiten will und die "schlechten" Objekte auswerten will.

Delphi-Quellcode:

LGuteList := TObjectList.Create;
LGuteList.ownsobjects := True;
LSchlechteList := TObjectList.Create;
LSchlechteList.ownsobjects := True;
try
  for a := 0 to 1000 do
   begin
     // hier irgendwie die Daten sammeln, die dem Objekt übergeben werden
     lFoo := TFoo.Create( irgendwelcheDaten );
     if lfoo.CreateError then
       LSchlechteList.add(lfoo)
     else
       LGuteList.add(lfoo)
   end;

  MachJetztWasMitDerGutenList;

  if IchWillDieSchlechteListAuswerten and (LSchlechteList.count>0)   then
    MachJetztWasMitDerSchlechtenList;
   
finally
  LGuteList.free;
  LSchlechteList.free;
end;

Was ist daran nicht sauber und warum brauche ich hierbei Glück?

[Dejan Vu]

Leute, einfach keine Logik in den Konstruktor.

Wenn es eine Logik für die Eigenschaft 'bin ich gültig?' gibt, wieso sollte man das über den Konstruktor abbilden? Das ist doch... nun ... ungünstig.

[stahli]

So etwas wollte ich vorhin auch schreiben. Hatte es aber nicht so schön auf den Punkt gebracht.

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1297573)

Leute, einfach keine Logik in den Konstruktor.

Wenn es eine Logik für die Eigenschaft 'bin ich gültig?' gibt, wieso sollte man das über den Konstruktor abbilden? Das ist doch... nun ... ungünstig.

:thumb:

Die einzige Logik die da rein gehört ist das Validieren der Argumente und wenn da etwas nicht passt, dann werfen wir eine Exception.

[Der schöne Günther]

Siehe auch:

Zitat:

Zitat von Der schöne Günther (Beitrag 1292645)

Etwas off-Topic:
Eins habe ich anfangs auch immer gemacht, mittlerweile bereue ich es heftigst: Im Konstruktor eines Objekts anfangen, irgendwelche Dinge zu tun. Hier sogar Kommunikation starten, auswerten, was auch immer. Das ist einer der heftigsten Fehler den ich durchgehend getan habe.

Eine Zusammenfassung in ein paar Zeilen warum nicht liefert der Google C++ Styleguide: Link.
Auf Delphi trifft das natürlich genauso zu.

Wochenend-(Urlaub?)Lesestoff dazu: Link.