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