In welcher Methode bin ich?

[s-off]

Zitat von DGL-luke:

Der Pärprozessor ersetzt __FUNCTION__ durch einen literalen string, der der bezeichnung der aktuellen methode entspricht. D.h. globale Variable "string CurrFunc = "";", in jeder Methode "CurrFunc = __FUNCTION__", bei Exceptions o.ä. CurrFunc ausgeben.

Könnte ich nicht genau so gut in jeder Methode der globalen Variable direkt den Methodennamen zuweisen?
__FUNCTION__ hätte doch nur den Vorteil, dass ich ggf. Änderungen am Methodennamen nicht nachziehen müsste, oder?

[Khabarakh]

Schau dir doch mal Ollis Nutzung von __FUNCTION__ an, das ergibt schon ein wenig mehr Sinn .
Interessant wäre doch eine DLangExtension oder Ähnliches, die jeden raise-Aufruf mit solchen Informationen spickt, da würde nicht einmal das fehlende CodeInsight stören.
Ansonsten, jo... System.Exception.StackTrace ftw .

[negaH]

Zitat:

Könnte ich nicht genau so gut in jeder Methode der globalen Variable direkt den Methodennamen zuweisen?
__FUNCTION__ hätte doch nur den Vorteil, dass ich ggf. Änderungen am Methodennamen nicht nachziehen müsste, oder?

Ja du hast schon Recht. In Delphi muß man es so machen für die gleiche Funktionalität die per Präprozessor eben in C geht. Der Präprozessor ist ja qausi nur ein Text-/Makroparser der dynamisch den Source ergänzt. Technisch gesehen entstehen die gleichen Vor- und Nachteile dieser Methode.

Gruß Hagen

[negaH]

Zitat von sirius:

Zitat von negaH:

@Sirius, ja das ist schon kompliziert besonders weil die Addresse an der die Exception ausgelösst wurde durch Delphi manches mal falsch berechnet wird, statt +4 Offset mit +5 Offset.

Das ist mir noch nicht aufgefallen. Wo denn? Der nimmt doch einfach die Rücksprungadresse nach "Raise" (bzw. RaiseExcept).
Mein größtest Problem sind eher HandleAnyException und wo self liegt. Aber wenn man jetzt in den Methoden anfängt extra Infos zu hinterlegen, dann kann man doch auch gleich an die Exception-Klasse eigene Eigenschaften mitgeben.


(Unter TP war ich noch nicht so tief in die Materie eingestiegen.)

Das bezieht sich auf das "AT" Postfix einer Exception.

raise Exception.Create('Test') at @MeineMethode. Nachvollziehen konnte ich diesen Fehler in Delphi 5, später habe ich das nicht mehr benutzt noch getestet.

Gruß Hagen

[Muetze1]

Zitat von s-off:

Zitat von DGL-luke:

Der Pärprozessor ersetzt __FUNCTION__ durch einen literalen string, der der bezeichnung der aktuellen methode entspricht. D.h. globale Variable "string CurrFunc = "";", in jeder Methode "CurrFunc = __FUNCTION__", bei Exceptions o.ä. CurrFunc ausgeben.

Könnte ich nicht genau so gut in jeder Methode der globalen Variable direkt den Methodennamen zuweisen?
__FUNCTION__ hätte doch nur den Vorteil, dass ich ggf. Änderungen am Methodennamen nicht nachziehen müsste, oder?

Deutlich mehr Arbeit: theoretisches Beispiel:

- 2 Funktionen. Func1 und Func2
- Grundlage: Func1 ruft Func2 auf; globale Variable __FUNCTION__ vorhanden
- Abflauf:

* Func1 angesprungen, setzt globale Variable auf "Func1"
* Func1 ruft Func2 auf
* Func2 angesprungen, setzt globale Variable auf "Func2"
* Func2 kehrt zurück
* Func1 logt __FUNCTION__ wird in der Log zu "Func2"

Ergo: Leider müsstest du dann ganz gewissenhaft nach eigentlich jedem Funktions-/Methodenaufruf die Variable erneut setzen.

Und zur Frage ob Präprozessor oder Compiler: Ich habe auch schon beide angesprochene Möglichkeiten gelesen (Compiler kümmert sich um __FUNCTION__ genauso wie Prärprozessor...) von daher scheint es eher davon abzuhängen wer wie die Compiler/Präprozessor nach eigenem Ermessen gebaut hat.

[Hawkeye219]

Hallo,

Zitat von Muetze1:

Ergo: Leider müsstest du dann ganz gewissenhaft nach eigentlich jedem Funktions-/Methodenaufruf die Variable erneut setzen.

Die Alternative wäre ein (globaler) Stack, der zu Beginn und am Ende jeder Routine aktualisiert wird. Dies hätte den Vorteil, im Fehlerfall eine Aufrufreihenfolge "frei Haus" zu bekommen, erfordert aber auch etwas Disziplin (Klammerung durch TRY..FINALLY).

Gruß Hawkeye

[sirius]

@Hawkeye Man kann so einiges machen. Aber ein allgemeine Lösung gibt es (anscheinend) unter Delphi nicht. Also muss man spezielle Sachen finden. Dazu bräuchte man aber mehr Infos zum Problem...

Zitat von negaH:

Nachvollziehen konnte ich diesen Fehler in Delphi 5, später habe ich das nicht mehr benutzt noch getestet.

Sehe ich nicht (D7). Egal.