Problem mit virtuellen Methodenaufrufen im Constructor

[Zacherl]

Hallo zusammen,

ich habe ein schwerwiegendes Problem in meinem aktuellen Klassendesign. Meine Komponenten erhalten von sich selbst oder von anderen Komponenten Nachrichten (keine Window Messages!), welche dann in virtuellen Methoden abgearbeitet werden.

Nun habe ich folgendes Problem:
1) Basisklasse führt im Constructor eine Operation aus, die dazu führt, dass eine der virtuellen Methoden aufgerufen wird
2) abgeleitete Klasse hat diese Methode überschrieben und greift z.b. auf eine Liste zu
3) die Liste kann allerdings erst nach Aufruf des originalen Constructors initialisiert werden und ist somit zum Zeitpunkt der Nachricht undefiniert
4) Access Violation

Gut, hier könnte ich einfach auf nil prüfen, doch bei anderen Aktionen würde ich durch "ignorieren" der Nachricht weitere Folgefehler auslösen.

Hat hier jemand einen Tipp für mich? Habe gesehen, dass es Methoden wie AfterConstruction gibt. Aber können die mir hier helfen?

Viele Grüße
Zacherl

[sahimba]

Zitat von Zacherl:

Habe gesehen, dass es Methoden wie AfterConstruction gibt. Aber können die mir hier helfen?

Durchaus, da dann alle Konstruktoren "durchgelaufen" sind. Verschiebe also den Aufruf der virtuellen Methode dorthin.

Grüße,
Stefan

[Furtbichler]

Ein Konstruktor sollte nie eine Aktion auslösen, sondern nur und ausschließlich Datenstrukturen initialisieren. Befolge diese Grundregel und Du hast weniger Probleme (programmiertechnisch).

[Zacherl]

Danke euch beiden. Konnte mein Problem durch Überschreiben der AfterConstruction() Methode lösen

[Furtbichler]

Hi,

dein lokales Problem mag damit gelöst sein, aber trotzdem schaffst Du es nun, das deine Klasse schon beim Aufruf des Konstruktors eine Exception wirft (natürlich kann das immer passieren, EOutOfMemoryException z.B.). Dein Konstruktoraufruf ist ja i.a. außerhalb des Try-Finally und wird somit nicht ordentlich abgefangen.

Ich würde mir überlegen, ob deine Klassenfamilie nicht mit einer Methode à la 'Initialize' besser bedient wäre. Denn die könnte innerhalb des Try-Finally aufgerufen werden.

Meine persönliche Meinung, is klar.

[sahimba]

Siehe auch (wenngleich .NET)
http://msdn.microsoft.com/de-de/libr.../ms182331.aspx

[Zacherl]

Zitat von Furtbichler:

Hi, dein lokales Problem mag damit gelöst sein, aber trotzdem schaffst Du es nun, das deine Klasse schon beim Aufruf des Konstruktors eine Exception wirft (natürlich kann das immer passieren, EOutOfMemoryException z.B.). Dein Konstruktoraufruf ist ja i.a. außerhalb des Try-Finally und wird somit nicht ordentlich abgefangen.

Ich bin selbst absolut kein Fan von Exceptions, die im Konstructor ausgelöst werden (TFileStream und Konsorten), in diesem Falle ist es vom logischen Konzept her aber nicht besser machbar. Meine Klasse erwartet im Konstruktor einen Parent, bei dem sie sich dann als Child Komponente registriert. Ist dieser Parent Wert nicht gesetzt, muss ich wohl oder übel eine Exception schmeißen. Die anderen Aktionen, die ich vorher unnötigerweise im Konstruktor ausgeführt habe, konnte ich jetzt aber in dafür vorgesehene Methoden auslagern

[Medium]

Das müsste sich doch ebenfalls über eine Methode SetParent(), oder gar eine hübsche Property mit Setter machen lassen - oder übersehe ich hier etwas?

Edit: Etwas von hinten durch die Brust, aber ggf. auch ein Weg: Als letztes im Konstruktor eine User-Message mit Pointer auf den Parent an den Aufrufer posten (für das Handle ließe sich ja ggf. auch der Parent-Parameter missbrauchen), und in diesem dann auf die Message mit diesem SetParent reagiern. Dann löst doch der Konstruktor das Setzen des Parents aus, aber tut es nicht wirklich. Etwas seltsam, gebe ich zu, aber wenn es denn sein muss
Wenn das Vorhandensein des Parents nur für weitere Operationen mit der Klasse nötig ist, und im Konstruktor eigentlich funktional nicht genutzt wird, wäre es generell aber besser, die Methoden so zu gestalten, dass DIESE eine Exception werfen, wenn der Parent nicht gültig ist. Dann gib't die Exception nur bei der verwendung, nicht beim Erzeugen. Besser finde ich.