Mögliche Exceptions eines Objektes herausfinden

[Delphi.Narium]

Man, das soll doch keine fertige Lösung sein, sondern nur ein Hinweis darauf, dass bei Delphi ein Grep dabei ist, mal drei Lösungsansätze für Teilmengen dabei und dann bitte gefälligst selbst nach der für den (nicht näher beschriebenen) Einzelfall suchen.

Grep kann reguläre Ausdrücke. Jetzt bist Du dran, weist ja zuweilen darauf hin, dass man damit viel machen kann. Sei so gut und liefere den passenden regulären Ausdruck, der alles, was Du jetzt meinst mit abfrühstücken zu müssen, liefert.

ff

[Jost Riedel]

Und was ist mit Exceptions, die nicht von System.SysUtils.Exception abgeleited sind?

Sowas ist leider (immer) noch möglich.

[himitsu]

Theoretisch ist es möglich, aber praktisch basiert die komplette Fehlerbehandlung darauf, somit sollte man sowas nicht machen.

Fehlerdialoge usw. zeigen sowas nicht an
und auch das except on E: Exception do ignoriert sowas. (wirkt dann ähnlich wie ein Abort/EAbort, außer dass es am ersten EXCEPT mit einem ON-DO abbricht)



Das "leider" war Absicht. (auch wenn es seit Einführung vor Jahrzehnten nie "richtig" benutzt wurde)



Ja klar kann RegEx viel, aber hier fängst dann an das RegEx rekursiv zu benutzen ... das ist dann bissl zuviel des Guten.
Dagegen ist der Weg über die RTTI ein Klacks. (nach dem Kompilieren)

[Jost Riedel]

Zitat von himitsu:

Theoretisch ist es möglich, aber praktisch basiert die komplette Fehlerbehandlung darauf, somit sollte man sowas nicht machen.

Fehlerdialoge usw. zeigen sowas nicht an
und auch das except on E: Exception do ignoriert sowas. (wirkt dann ähnlich wie ein Abort/EAbort, außer dass es am ersten EXCEPT mit einem ON-DO abbricht)

Du machst sowas nicht, und selbst ich mache das schon seit über 20 Jahren nicht mehr. Aber das ist hir nicht die Fragestellung: Es geht darum, aus einem großvolumigen, schlecht dokumentierten Sourcecode etwas sinnvolles zu extrahieren. Und da kann alles drin sein, was der Compiler akzeptiert.

[himitsu]

Klar, es gibt Codes, wo Exceptions zur "normalen" Flusssteuerung benutzt werden und wo z.B. Daten-Objekte via Raise als Result nach außen durchgereicht werden,
aber sowas würde ich ignorieren, da man solch ein Verhalten "vergessen" kann.

[Uwe Raabe]

Zitat von himitsu:

Klar, es gibt Codes, wo Exceptions zur "normalen" Flusssteuerung benutzt werden und wo z.B. Daten-Objekte via Raise als Result nach außen durchgereicht werden,
aber sowas würde ich ignorieren, da man solch ein Verhalten "vergessen" kann.

Sowas musst du auch ignorieren, da du sonst diese Flusssteuerung außer Kraft setzt.

[himitsu]

Jo, sowas vergessen wir einfach. Wer sowas macht, hat es nicht anders verdient.

[Delphi.Narium]

Wie wäre es denn, wenn wir den Threadersteller erstmal mit den bisher gegebenen Vorschlägen arbeiten lassen?

Das könnte schonmal 'ne nicht unerhebliche Menge an Ergebnissen liefern.

Und wenn dann noch was unklares überbleibt, kümmern wir uns um die (mehr oder weniger) exotischen Ausnahmen bei der Erstellung von Ausnahmen

Oder einfach mal nicht drauf hinweisen, dass es noch Sonderfälle gibt, sondern einfach mal direkt 'nen umsetzbaren Vorschlag, wie man die genannten Sonderfälle sinnvoll und sicher identifizieren kann

Zitat von Jost Riedel:

Und was ist mit Exceptions, die nicht von System.SysUtils.Exception abgeleited sind?

Sowas ist leider (immer) noch möglich.

Frei nach dem Motto: Und wie kann ich sie (weitgehend) sicher finden?

Zitat von himitsu:

Und was ist mit vererrbten Exceptions, die nicht direkt von Exception abgeleitet wurden?

Dito

Erster Vorschlag: Mal alle Exceptions der Sorte EIrgendeinName = class(Exception); suchen.
Mit dem Ergebnis suchen, ob es irgendwo ein EIrgendeinAndererName = class(EIrgendeinName); gibt.
Mit dem Ergebnis suchen, ob es irgendwo ein EIrgendeinNochAndererName = class(EIrgendeinAndererName); gibt.

Upps: Rekursionsgefahr.

Vielleicht doch erstmal nur mit dem Einfachen anfangen?