Mögliche Exceptions eines Objektes herausfinden

[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)

[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?

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

[dummzeuch]

Zitat von Delphi.Narium:

Bei meinem Delphi gibt es im BIN-Verzeichnis 'ne Grep.exe. Wenn ich die so aufrufe

Code:

c:\Delphi7\Bin>grep -dni except "e:\delphi\*.pas > grep.except.log"

gräbt die sich durch alle .pas-Dateien in dem Verzeichnis und raus kommt eine Datei in der alle Dateiname, die Zeilennummer und die Zeile stehen, in der die Zeichenfolge Except zu finden ist.

Und wenn man schon dabei ist, kann man mal schauen, an wie vielen Stellen das raise oder das Create fehlt:

Delphi-Quellcode:

if SomeCondition then
  raise Exception('some error message');

Grep nach "raise Exception\(" und "raise e[a-z]*\(".

und

Delphi-Quellcode:

if SomeCondition then
  Exception.Create('some error message');

Grep nach " e[a-z]*\.Create\("

(Davon gab es eine sogar in er Delphi 10.2 RTL.)

Ich habe damals darüber geblogt:

When an exception is nil in the exception handler

[himitsu]

PS: Vergesst auch nicht die ErrorCodes.
Error(reOutOfMemory);

Und für gewisse "Fehler" gibt es auch schon von Haus aus Funktionen.

Delphi-Quellcode:

Abort;  // ihr dürft aber auch gern raise EAbort.Create('irgndwas, wird eh ignoriert'); machen

OutOfMemoryError;  // und wenn der Speicher zu wenig ist, dann wurde dafür das Objekt schon vorher erstellt

[Caps]

Danke an alle für Eure Ideen!
Es sind nicht wirklich 17.000 Exceptions, aber ich sehe meine Frage dahingehend beantwortet, dass es keinen einfachen Weg gibt, sich die möglichen Exceptions in einer Art "Exception-Übersicht" anzeigen zu lassen. Es gibt ja auch kein "throws" o.ä. in Delphi. Naja, passt. Ich werde eben danach suchen.

lg Caps

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