Zur Laufzeit, Zeilennummer feststellen

[günni0]

Gerade mal mit einer Schleife und ProcByLevel nachgebaut.

Zitat:

TLogFunctions.doExceptionLog
Form.Main.TForm1.AppExceptionHandler
Forms.TApplication.HandleException
Classes.StdWndProc$qqsp6HWND__uiuiui

FileByLevel dementsprechend

Zitat:

uLog.pas
<projektname>.Form.Main.pas
Vcl.Forms.pas
System.Classes.pas

Danach kommt nix mehr. Darf man bei sowas keinen eigenen HandleException haben?

[himitsu]

Application.HandleException ist da, wo es bei dir schon raus ist.

Delphi-Quellcode:

function HandleMessage;
try
  CallWindowsEvents;  // hier hat es in einer unterfunktion geknallt
except
  HandleException;  // aber hier ist dein HandleException-Event drin, also ist ein Stacktrace von HIER aus sinnlos
end

System.ExceptObject ... das entspricht dem on E: Exception im EXCEPT-Block
System.ExceptAddr ... hier hatte es geknallt
System.ReturnAddress ... mein Caller (bzw. der Befehl danach)

Schau dir mal die Exception-Klasse genau an. Da kann man sich für die Stacktrace-Behandlung registrieren.
Also während die Exception ausgelöst wird ... da kannst du den Stacktrace auslesen und innerhalb des aktuellen Exception-Objektes speichern. (Delphi bietet nur die Zugangspunkte, aber ohne eigene Funktion)
Und in der anschließenden Exceptionbehandlung kannst du über das Exception-Objekt an dessen Stacktrace wieder rankommen.

[günni0]

Wie loggt ihr denn dann Fehler wenn nicht mit einer Exception-Prozedur? Ich kann schlecht überall try-except hinschreiben.

[himitsu]

Mit Try-Except und alles was wir vergessen haben über TApplicationEvents.OnException (nicht direkt an Application)

[günni0]

Also doch try-except. Ich dachten immer man soll sauber funktionierenden Code schreiben und try-except sei nur eine Notlösung.

Zitat:

über TApplicationEvents.OnException (nicht direkt an Application)

Den Teil verstehe ich nicht. Dann hat man ja aber wieder keinen Zugriff auf genaue Fehlerquellen.

[himitsu]

Hier haben wir ein in Jahrzehnten gewachsenes Programm aus mehreren EXEn, vielen DLLs und massig BPLs.
Das wurde von Turbo Pascal (DOS) über Delphi 7 (Windows), aktuell Delphi XE und parallel neu für 10.x .
533 vorwiegend eigene Units, ~60 Projekte (EXE/DLL), ~30 Packages und vielen Fremdkomponenten.
Wo mehrere Leute drin rumpfuschen .... mal ehrlich, erwartest du wirklich, dass es da alles reibungslos funktioniert?

Neben Eurekalog sind da noch ein paar eigene Exceptionbehandlungen mit Erweitern der Exception-Message, da Eurekalog auch nicht immer den Stacktrace ausreichend aufbauen kann.

[Nathan]

Hatten dies auch schon, das in unseren Exe beim Kunden AVs wie "Access violation at address 005CDF76 in module 'DummyProject. exe'. Read address 00000000." aufgetreten. Hat dann immer jeder gesagt, weis nicht wo der Fehler liegt. Bin dann hin gegangen und lies die Exe mit MAP Files kompilieren. Passend zur Exe Version wurde die entsprechende MAP Datei gesichert. Verteilt an den Kunden wurde nur die Exe.

Hat jetzt ein Kunde eine AV, kann ich mit einem selbst geschriebenen Programm, Zeilennummer der Exception filtern.

Das Programm hab ich unter Github https://github.com/Thurnreiter/Thurnreiter.MapFile veröffentlicht.

Ein Aufruf von "NathanMapFile.exe -MapFilename:.\DummyProject.map -CrashAddress:$005CDF76" ergibt dann:

Offset: 6
Codeline: 34
Startaddress from Module: $001CCCA0
Name of procedure from address: Unit1.TForm1.Button1Click
Sourcename from address: Unit1.pas

Voraussetzung ist, zur Exe eine passende MAP Datei. Es ist dann auch keine IDE nötig. Vielleicht hilft dir das Programm was.