Wie mit dem Fehler in einer Klasse umgehen?

[bernau]

Ich würde der Klasse ein Property spendieren.

Delphi-Quellcode:

Property CreateError:boolean;
Property CreateErrorInfo:String;

Beim Erzeugen prüfst du die Bedingungen und setzt dem entsprechend das Property (Nur readonly).

Nachdem alle Objekte erzeugt wurden kannst du bei allen Objekten diese Property überprüfen und die fehlerhaften Objekt ggf wieder frei geben.
Kann man natürlich auch nach jedem erzeugen der Klasse direkt prüfen und freigeben.

[Der schöne Günther]

Aber was hat man denn davon? Einen Haufen "kaputter" Objekte bei denen man dann in einem String nachschauen kann was da schief gelaufen ist? Muss ich jetzt bei jedem Objekt vor der ersten Benutzung schauen, ob bei dem not CreateError ist? Und warum sollte ich ein nicht arbeitsfähiges Objekt überhaupt nicht direkt wieder zerstören? Wir programmieren doch keinen Sozialstaat...

Ich finde das schafft nur zusätzliche Arbeit und Unsicherheiten und hat eigentlich überhaupt keinen Nutzen. Oder ich sehe ihn noch nicht.

Aber mit einem konkreten Beispiel könnte man sicher besser drüber reden.

[Sir Rufo]

Wenn ich Klassen erstelle, dann wird im constructor als Erstes die Gültigkeit der Argumente geprüft.

Delphi-Quellcode:

constructor TFoo.Create( ABar : TBar );
begin
  // Guard-Section
  if not Assigned( Bar ) then
    raise EArgumentNilException.Create( 'ABar' );

  inherited Create;

  FBar := ABar;
  FSomething := TSomething.Create;
end;

destructor TFoo.Destroy;
begin
  FSomething.Free;
  inherited;
end;

Wird jetzt eine Instanz erzeugt, dann ja nach diesem Pattern:

Delphi-Quellcode:

LFoo := TFoo.Create( nil ); // Bei einer Exception ist hier schon Ende
try
  // mit LFoo arbeiten
finally
  LFoo.Free;
end;

In einer Schleife

Delphi-Quellcode:

LList := TObjectList.Create;
try
  while LList.Count < 1000 do
  begin
    LList.Add( TFoo.Create( nil ) ); // Bei einer Exception ist hier schon Ende
  end;

  // mit LList arbeiten

finally
  LList.Free; // aber das hier wird auch noch abgearbeitet
end;

Also immer alles sauber

@bernau

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

[bernau]

Zitat von Sir Rufo:

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

[Der schöne Günther]

Siehe auch:

Zitat von Der schöne Günther:

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.

[Sir Rufo]

Zitat von 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.

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

[Popov]

Ich glaube ich kann damit etwas anfangen.

Im Grunde minte ich sowas in der Art. Ich hab die Aussagen oben durch den Code überprüft und es stimmt - es wird sofort der Destroy aufgerufen

Delphi-Quellcode:

type
  TErrorTest = class
    Wert: Integer;
    constructor Create;
    destructor Destroy; override;
  end;

constructor TErrorTest.Create;
var
  a: Integer;
begin
  a := 0;
  Wert := 1 div a;
end;

destructor TErrorTest.Destroy;
begin
  ShowMessage('Es hat Bum gemacht.');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  o: TErrorTest;
begin
  o := TErrorTest.Create;
  try
    ShowMessage('Der Wert ist: ' + IntToStr(o.Wert));
  finally
    //o.Free;
  end;
end;

Für die zweite Frage habe ich auch eine Lösung. Die Schleife wird in einem Try Except Block ausgeführt. Gibt es einen Fehler, geht es raus.

[DeddyH]

@ Günther: Sehe ich genauso. Entweder ein Objekt ist funktionsfähig, dann kann ich es ohne groß nachzudenken benutzen, oder es ist im A***h, dann muss es wieder weg. Bei einer Property besteht die Gefahr, dass sie nicht ausgewertet wird und man munter die vergriesgnuddelte Instanz benutzt.