Zitat von
Hansa:
Schon mal versucht, eine abstracte Methode zu debuggen ?
Du meinst, wenn ein EAbstractError ohne weitere Hinweise und ohne definierten Stop im Quelltext kommt?
Nun, wenn man beim sinnvollen Gebrauch von abstract-Methoden die Warnungen des Compilers nicht in den Wind schlägt, ist das möglich, bzw. der Fehler dürfte gar nicht erst passieren.
Zitat:
[Warnung] Unit1.pas( 48 ): Instanz von 'TAbleitung' mit der abstrakten Methode 'TBasis.TestProc' wird angelegt
Wenn man z.B. eine fremde
Unit einsetzt, die
tatsächlich notwendige Implementierungen in Ableitungen auslässt (ist ja schon grober Frevel!), dann ist mir die Fehlermeldung immer noch lieber, als ein stillschweigendes Gar-Nichts-Machen bei deiner leeren Virtuell-Methoden-"Lösung". Das führt dann nämlich zu Logikfehlern im Programm und/oder erst später zu Programmabbrüchen, die genau so schwer zu orten sind. Ursache ist ja immer noch die vergessene Implementation einer Methode.
Ne, ne, dann lieber eine klare Fehlermeldung, die mir deutlich sagt: Mit dieser Klasse stimmt was nicht!
Zitat von
Hansa:
[...]irgendwann habe ich die Implementation dieser Prozedur tatsächlich vergessen.[...]und ich verwende "virtual" statt "abstract" und schreibe notfalls in der Ur-Klasse nur : begin end;
Seitdem ist Ruhe.
Wie oben geschrieben: Ruhe ist das allerletze, was ich bei einer derart fehlerbehafteten Klasse haben möchte.
