Objekterstellung im Konstruktor abbrechen

[mschaefer]

Hallo Marco,

irgendie dreht sich mir der Magen um wenn ich im Creator einen Destroy einleiten soll. Das ist logisch schwierig!
Man könnte natürlich einen Timer erstellen, der bei fehlenden Daten im Timerevent ein Destroy auslöst, aber den für mich korrekten Weg würde ich darin sehen ein Datentestobject die Datenverfügbarkeit testen zu lassen und nach Ergebnis dann das Formular aufzubauen. Das würde auch einiges an Speicherschiebereien sparen, denn Formulare sind doch große Objecte.

Viele Grüße // Martin

[alzaimar]

Hi Martin,

ich bin zwar nicht gemeint, aber ich schalte mich mal zwischen: Ich kann Deinen Einwand zwar nachvollziehen, hier aber nicht sehen. Meine Interpretation eines Konstruktors ist hier, wie der Name schon sagt, eine Aufforderung zum Erzeugen eines Dingens. So, wie z.B. ein Haus bauen.
Ich sage also: "Ich gebe Dir den Auftrag, ein Haus zu bauen, Danke schon mal". Es ist doch legitim, wenn das, aus welchen Gründen auch immer, nicht hinhaut. Das war die Intention von Marco.

Natürlich ist es Quatsch, die grundlegende Prüfung der Vorbedingungen in den Konstruktor zu stopfen. Genauso fatal wäre es, um beim Vergleich zu bleiben, den Auftrag fürs Häusle bauen ohne vorherige Prüfung zu geben.

Jetzt weiss ich auch, worauf Du hinaus willst: Der Konstruktor sollte also nicht das Haus bauen, sondern zunächst, sagen wir, die Absicht manifestieren. Danach erfolgt die Prüfung der Bonität, der Kosten, des Bauträgers etc. Wenn hier was schiefgeht, dann wird der Vorgang eben abgebrochen....

So gesehen, sollte der Konstruktor noch gar keine konkreten Aufgaben übernehmen oder Werte festsetzen, sondern nur die Voraussetzungen schaffen.

Doch, damit kann ich mich anfreunden. Nicht, das ich mir widerspreche, ich plädiere unbedingt für eine Flusskontrolle mit Exceptions (statt ständig irgendwelche Returncodes auszuwerten). Aber das Wesen eines Konstruktors wäre demnach nur die Bereitstellung eines Gerüstes ('Framework'), mit dem man die Aufgabe angehen kann. Der Aufruf des Konstruktors kann schiefgehen, das wäre aber ein GAU, wie Speicher voll, Flasche leer oder so was.

Interessanter Aspekt.

[mschaefer]

N´abend Alzaimar,

ja Deinen Vergleich finde ich gut. Wollte mich in die Diskussion zu den Exception da nicht einmischen.
Habe halt noch nie was im Constructor abgebrochen und da erwarte ich es in meinem Code eigentlich auch nicht.

Grüße // Martin

[Robert Marquardt]

Wenn eine Exception im Konstruktor ausgeloest wird, dann wird automatisch der Destruktor aufgerufen.
Man muss also nur den Code im Konstruktor und Destruktor auf einander abstimmen, da die normale
Implementierung des Destruktors die vollstaendige Initialisierung im Konstruktor annimmt.
Wenn man nun die Erstellung des Objekts in try except einschliesst, dann bekommt man das gewuenschte Ergebnis.

[Marphy]

Hallo zusammen,
da muss ich doch auch noch ein Wörtchen zu sagen...

Zitat von mschaefer:

irgendie dreht sich mir der Magen um wenn ich im Creator einen Destroy einleiten soll. Das ist logisch schwierig!
Man könnte natürlich einen Timer erstellen, der bei fehlenden Daten im Timerevent ein Destroy auslöst

Wenn du den zuletzt genannten Weg besser oder gar eleganter findest, ist dir wirklich nicht mehr zu helfen... Bei allem Respekt, aber dieser Vorschlag ist doch überflüssig.

Zitat von mschaefer:

aber den für mich korrekten Weg würde ich darin sehen ein Datentestobject die Datenverfügbarkeit testen zu lassen und nach Ergebnis dann das Formular aufzubauen.

Ja, das geht natürlich. Aber dass z.B. die Datei nicht gelesen werden kann, ist ja nur eine von vielen, vielen möglichen Fehlerquellen, zumal meine Anwendung schon ein wenig komplexer ist als z.B. ein einfacher Texteditor.

Zitat von mschaefer:

Das würde auch einiges an Speicherschiebereien sparen, denn Formulare sind doch große Objecte.

Deine Aussagen ergeben einen einzigen Widerspruch! Was wird wohl mehr "Speicherschiebereien" verursachen: Eine aufwendige Vorprüfung aller nur erdenklichen, möglichen Fehler (welche - o Schreck - auch Festplattenzugriffe erfordern würde ) oder das Abbrechen der Objekterstellung bei einem Fehler.
Was wäre dein "Lösungsweg" nur für eine Ressourcen- und Energieverschendung, wenn man bedenkt, dass vielleicht bei 100 Versuchen ein einziges Mal ein Fehler auftritt? Alle Prüfungen umsonst... Da dreht es mir den Magen um!

Zitat von alzaimar:

ich bin zwar nicht gemeint, aber ich schalte mich mal zwischen: Ich kann Deinen Einwand zwar nachvollziehen, hier aber nicht sehen. Meine Interpretation eines Konstruktors ist hier, wie der Name schon sagt, eine Aufforderung zum Erzeugen eines Dingens. So, wie z.B. ein Haus bauen.
Ich sage also: "Ich gebe Dir den Auftrag, ein Haus zu bauen, Danke schon mal". Es ist doch legitim, wenn das, aus welchen Gründen auch immer, nicht hinhaut. Das war die Intention von Marco.

Danke für die schützende Stellungnahme!

Zitat von alzaimar:

Jetzt weiss ich auch, worauf Du hinaus willst: Der Konstruktor sollte also nicht das Haus bauen, sondern zunächst, sagen wir, die Absicht manifestieren. Danach erfolgt die Prüfung der Bonität, der Kosten, des Bauträgers etc. Wenn hier was schiefgeht, dann wird der Vorgang eben abgebrochen....

So gesehen, sollte der Konstruktor noch gar keine konkreten Aufgaben übernehmen oder Werte festsetzen, sondern nur die Voraussetzungen schaffen.

Ich stopfe das Ganze doch nicht aus Spaß gerade in den Konstruktor.
Warum hätte es ein OnCreate()-Handler denn nicht auch getan? Weil bei einem auftretenden Fehler der Aufbau des Formulars nicht einfach wieder abgebrochen werden könnte (oder hat da jemand eine Idee?). Und es würde auch keinen Sinn machen, das nackte Formular ohne Daten vor sich zu haben...

Zitat von alzaimar:

Doch, damit kann ich mich anfreunden. Nicht, das ich mir widerspreche, ich plädiere unbedingt für eine Flusskontrolle mit Exceptions (statt ständig irgendwelche Returncodes auszuwerten). Aber das Wesen eines Konstruktors wäre demnach nur die Bereitstellung eines Gerüstes ('Framework'), mit dem man die Aufgabe angehen kann. Der Aufruf des Konstruktors kann schiefgehen, das wäre aber ein GAU, wie Speicher voll, Flasche leer oder so was.

s.o. (Man beachte, das ein Formular oder Control anders zu handhaben ist als eine einfache Klasse.)

Zitat von mschaefer:

Habe halt noch nie was im Constructor abgebrochen und da erwarte ich es in meinem Code eigentlich auch nicht.

Man sollte halt nicht immer nur von sich ausgehen...

@Robert:
Jaja, das ist mir schon klar. Dies schrieb ich ja bereits im "Root Posting".

Liebe Grüße, Marco

P.S.: Ich wollte hier niemanden auf irgendeine Weise angreifen oder runtermachen. Außer den Smilies kann man in ein Posting ja keinerlei Emotionen mit reinpacken, welche in einem Gespräch aber alles andere als unwichtig sind. Das nur nebenbei bemerkt...

[mschaefer]

Moin, moin,


In Alzaimar Beispiel findet sich im Creator das inherited am Procedureanfang. Dadurch durchläuft das Object Formular schon einiges an Allocations und Aufbauarbeit und nur die letzte Instanz ist noch nicht geklärt, das bestätigt den Speicherhinweis, da beisst die Maus kein Faden ab.

Sind Deine Prüfungen für mehrer Formulare eher gleichlaufend, dann würde ich meine Vorobjectmethode nicht wegwerfen. Zumahl Du wahrscheinlich eine zentrale Aufrufroutine haben wirst, wo die Formulare dynamisch aufgebaut werden, je nach Anwahl des Nutzers.

Sind die Prüfungen sehr Formularspezifisch sehe ich auch, dass die Constructor-Variante, (ja für mich was Neues, her damit) der übersichtlichere Weg ist, da alle Aufgaben in der Formularunit liegen, ok, klingt logisch, macht Sinn! -> Mach es so !


Uhps schon wieder Teatime, ja man hat so seine Verpflichtungen... -


Viele Grüße // Martin




// PS: Texteditoren mit vielen dynamischen Formularen sind ein Fall für den Papierkorb... //

[Marphy]

Hallo Martin,
wenn du deine Prüfungs-Methode überzeugend verteidigen willst, darfst du meinen entsprechenden Nachfragen nicht einfach ausweichen...

Zitat:

// PS: Texteditoren mit vielen dynamischen Formularen sind ein Fall für den Papierkorb... //

Aha, wieso das?

Gruß, Marco

[mschaefer]

Hi Marco,
sorry, der Computer darf heute leider nicht dauernd laufen...

Ja ok, ein Texteditor ist für mich keine Textverarbeitung oder IDE.
Sowas mag ich klein handlich und ohne viel Schnickschnack um eben mal eine Text zu edieren: halt Notepad und gut...


Wer sich schon über der die dynamische Verwaltung seiner Formulare Gedanken macht, programmiert daher mit hoher Wahrscheinlichkeit an etwas komplexeren, das liegt jedenfalls nahe. Das Thema dynamische Formulare ist für mich
interessant, da ich schon des längerem an einem MDI-System arbeite, wo Teile des MDI-Formulars noch sichtbar sind und die Clients je nach Funktion eingeblendet werden und die Tastatursteuerung natürlich über die Formulargrenzen erhalten bleiben muß. Also man kann mit sowas viel Zeit verbringen.

An einer Sache bin ich bisher leider auch immer noch gescheitett: Eignetlich wollte ich eine Komponente bauen, wo ich alle in frage kommenden Formulare als Liste lade. Die Komponente sollte dann nur Namen oder Nummer des Formulars bekommen, andere dann schließen und das entsprechende öffnen. Aber leider ist das daran gescheitert, das ich ja verschieden Objectypen erstellen muß und die habe ich bis daher nich in die Listenverwaltung bekommen. Na da geht wohl noch Wasser die Leine herunter....

Grüße // Martin

[alzaimar]

Ich kann mir ganz gut vorstellen, das beide Verfahren zu stabilen und übersichtlchem Code führen.
Der eine prüft eben explizit, der Andere geht das Risko ein, das die Karre gegen die Wand fährt, und räumt hinterher auf. Ich kann mich für beide Verfahren erwärmen, die Hauptsache ist doch, das man weiss, was man tut und das das Ergebnis stabil, übersichtlich und wartbar wird.

Wenn ich eine vollständige Fallunterscheidung hinbekomme, unter welchen Umständen etwas schiefgehen könnte, dann implementiere ich das. Wenn nicht, dann wird mit Try....Except gearbeitet. Nur Rückgabewerte à la 'aSuccess', die zeigen, ob etwas schiefgegangen ist, verkneife ich mir normalerweise, weil sie eben aus einer Folge von Anweisungen If..Then Anweisungen machen.

@mschaefer: Dein Problem hatte ich mal mit einem Pagecontrol (HideTabs=True) und einer Basisklasse (TModule, abgeleitet von TForm) gelöst, die in der Lage ist, sich auf einem TabSheet zu plazieren (Parent umbiegen). Das Hin-und-Herschalten geschieht über PageControl.ActivePageIndex. Auf einem TModule-Formular kann ich Actionlists definieren, die mit der Actionlist des MDI-Masters beim Modul-Umschalten verschmolzen werden: Ich habe so eine Grundfunktionalität, die über alle Module hin identisch sind, sowie für jedes Modul individuelle Aktionen, die nur dann sichtbar werden, wann das entsprechende Modul aktiviert ist.

[Flocke]

... und schließlich noch mein Senf

IMHO ist in so einem Falle die Prüfung bei der Erstellung immer sinnvoller als vorher einen vielleicht aufwändigen Test durchzuführen. Wer garantiert mir denn, dass es trotz vorheriger Prüfung klappt? Niemand!

Wenn du z.B. mit FileExists vorher prüfst, ob eine Datei existiert, dann kann es im Konstruktor dennoch sein, dass du sie nicht öffnen kannst (keine Rechte, Sperrung, etc.).

Auch kann z.B. ein Datensatz, den du vor dem Aufruf von Create überprüft hast, im Konstruktor schon wieder gelöscht sein.

Was habt ihr denn alle gegen Exceptions???

Was ist sooo schlimm daran, dass eine Box mit "Es eine Ausnahmebedingung vom Typ BlaBlaBla aufgetreten" kommt anstatt eurer eigenen Box mit "ich konnte die Datei nicht öffnen"?

Auf Exceptions muss man immer vorbereitet sein, denn unvorhersehbare Ausnahmebedingungen können immer auftreten. Und wenn man dieses Konzept sauber durchzieht, dann braucht man keine Vorab-Checks mehr!