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.