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