Wie mit dem Fehler in einer Klasse umgehen?

[Popov]

Ich schreibe gerade an einer kleinen Klasse und übergebe gleich in Create einige Angaben. Die müssen in Create übergeben werden. Natürlich prüfe ich einige der Angaben auf Plausibilität.

Frage 1;

Wenn die nicht gegeben ist, wie gehe ich mit dem Fehler um? Noch ist das Objekt nicht im Try Finally Block.

Frage 2:

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?

[Der schöne Günther]

Ich verstehe deinen try..finally-Block nicht. Wenn im Konstruktor eine Exception geworfen wird, dann wird automatisch nach dem Verlassen der Destruktor ausgeführt. Erst dann geht es in den Code zurück der das Objekt erzeugen wollte.

Auch: http://de.wikipedia.org/wiki/Fail-Fast

[himitsu]

Wenn es im Create Constructor eine Exception gibt, dann wird automatisch Destroy aufgerufen und nachfolgend die Exception nach außen weitergereicht.

Die Schleife, welche deine vielen Objektinstanzen erstellt und befüllt, kann via Try-Except die Fehler abfangen ... dort kann man (du) nun entscheiden was man machen will, wie z.B. Behandeln (etwas Anderes machen und nichts anzeigen), den Fehler weitergeben (

Delphi-Quellcode:

raise;

), eine Fehlermeldung anzeigen oder sonstwas.

Achtung: Der Destructor muß damit umgehen können, daß das Objekt eventuell nicht vollständig initialisiert wurde. (Create vorzeitig abgebrochen)

Zitat:

Ich verstehe deinen try..finally-Block nicht.

Delphi-Quellcode:

O := TObject.Create;  // hier knallt es, in dem Create drin
try
  ...
finally
  O.Free;  // wird natürlich nicht mehr aufgerufen ... gut so, denn O wurde eh nicht zugewiesen.
end;

[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

Delphi-Quellcode:

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

Delphi-Quellcode:

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 ;)

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

[himitsu]

Was man davon hat?
> Fehlerbehandlung / Fehlerkorrektur

Bei einer Datenladeklasse (z.B. XML) werden im Create die Daten geladen.
* man kann bei einem Ladefehler abbrechen und alles gleich wieder freigeben
* man kann aber auch den bisherrigen Zustand belassen und zumindestens die geladenen Teile verarbeiten, bzw. eine Fehlerbehebung durchführen und dann nochmal versuchen.


Aber ja, meistens sagt man "Oh kaputt ... weg damit".
Manchmal kann es aber gut sein, wenn man einen fehlerresistenteren Modus aktiviert und dann zumindestens teilweise was damit anfangen kann.

Nur weil ein Byte im JPEG einen Datenfehler hat, kann man sich meistens dennoch große Teile des Bildes ansehn.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1297556)

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

Das ist halt wie mit der Erziehung von Hunden:

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