Hallo zusammen,
wir habe eine Loggingkomponnente im Einsatz welche sich den Methodennamen und Klassennamen des aufrufers nimmt aus dem StackFrame
var method = new StackFrame(1).GetMethod();
var classType = method.ReflectedType;
Wir nutzen diese in einem Webprojekt gehostet auf dem IIS
Seit neustem fliegen wir hier mit einer NULL Reference Exception raus.
Das schlimme ist, wir sehen ja dadurch keine Logeinträge und Lokal können wir das Problem nicht nachstellen.
Hat jmd eine Idee woran es liegen könnte ?
P.S. NET 4.5 mit den Attributen dürfen wir nicht nutzen
Grüße
Je nachdem wo der Fehler fliegt steht halt kein StackFrame zur Verfügung. Der Fehler kann ja auch zB durch den Handler entstehen.
Typischer Fall dafür, dass man einfach auch auf null prüfen sollte...
P.S. NET 4.5 mit den Attributen dürfen wir nicht nutzen
Wer kommt denn auf diese Regel-Schnapsidee (sofern die Filter meinst), oder meinst Du die neuen Caller-Attribute?
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Mein Tipp wäre eher, dass method
gleich null
ist @Thread-Titel. Oder hast du schonmal irgendwo var foo = new Bar();
geschrieben, wobei foo
in der Zeile danach null
war? 😃
Das schlimme ist, der StackFrame steht zur Verfügung, es wird keine Exception geworfen, es wird nur was normales geloggt. Bisher hat es immer funktioniert, auch auf den Test und Produktionsservern, auf den Produktionsservern läuft es bisher
Es muss also einen bestimmten Grund haben
Und ja ich meine die CallerNameAttribute.
Das 4.5 dürfen wir im Bankenumfeld noch nicht nutzen 😉
Ja der Grund ist: Du prüfst nicht auf null.
Prüf alles auf null, dann kennst Du die Ursache.
So ist das nur stupides Raten und bringt keinen weiter.
Und nein: im IIS-Umfeld steht der Stacktrace nicht überall zur Verfügung.
BhaaL hat zudem auch nicht unrecht.
PS: ich kenne Software mit .NET 4.5 im Bankenumfeld, die sehr wohl die Caller-Informationen nutzen.
Ich würde es also nicht pauschalisieren sondern einfach sagen "wir wollen es aktuell nicht nutzen".
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Mittlerweile bin ich doch weiter : Es scheint, dass der Code Optimizer beim compilen alles Inline macht. Dadurch steht der StackFrame nicht zuer Verfügung.
[MethodImpl(MethodImplOptions.NoOptimization)]
Scheint erstmal zu wirken.
Edit für evtl. andere leute:
Lasst die Finger von solchen Optimierungen. Ein Code sollte nie vom StackeFrame abhängig sein.
Ich werde unsere Loggingkomponnente umbauen und mit strings arbeiten.
grüße
Anders ausgedrückt: man sollte wissen, was man tut.
Denn gerade AgressiveInlining bei .NET 4.5 _kann _enorme Performance-Potenziale bei Schleifen und If-Abfragen bewirken - vorausgesetzt man verwendet es korrekt, wissentlich und mit Bedacht.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code