Hallo Community,

ich habe folgendes Problem:

Wenn eine Exception geworfen wird und ich auf "Anhalten" klicke, lande ich mit dem Debugger in der Zeile, in der die Funktion aufgerufen wird, die die Exception auslöst, nicht aber in der Funktion selbst.

Angenommen ich implementiere 2 Funktionen A() und B(). A() ruft in einer Zeile B() auf. B() greift in irgendeiner Zeile beispielsweise auf einen ungültigen Array-Index zu. Dann erhalte ich die Exception "Ungültiger Listenindex ..." (oder ähnlich). Klicke ich dann auf "Anhalten", stehe ich in Funktion A(), und zwar dort, wo B() aufgerufen wird. Es gibt dann leider keine Möglichkeit, herauszufinden, wo genau in Funktion B() die Exception ausgelöst wird. Ich kann das Programm abbrechen, einen Breakpoint zu Beginn von B() setzen, und dann Schritt für Schritt bis zur Exception debuggen. Das ist auf Dauer lästig, vor allem wenn die Exception nicht bei jedem Funktionsaufruf von B() ausgelöst wird.

Ich habe den Verdacht, dass der Compiler bestimmte Funktionen automatisch "inlinen" tut aus Optimierungsgründen, also aus A() und B() eine Funktion macht. Merkwürdig ist aber, dass dieses Verhalten ausnahmslos immer auftritt. Bei jeder Exception, bei der ich anhalte, lande ich grundsätzlich nur in der aufrufenden Funktion. Wenn das tatsächlich eine Optimierung ist, kann ich das dann irgendwo abschalten?

Für jegliche Hilfe bin ich sehr dankbar!

Gruß,
Sankt Rochus

Wie wär's mit einem Breakpoint in der Funktion, in der der Fehler auftritt? Dann stepst du soweit durch, bis der Fehler kommt, und schon hast du ihn am Wickel

Der Aufrufstack beinhaltet die Funktion B auch nicht?

Zitat von Sankt Rochus:

Merkwürdig ist aber, dass dieses Verhalten ausnahmslos immer auftritt.

In einem simplen Beispiel passiert das hier zumindest nicht. Der Debugger bleibt exakt in der Zeile stehen, wo die Exception auftritt.

zusammenfalten · markieren

Delphi-Quellcode:

procedure B;
var
  I: Extended;
begin
  if true then begin
    I := 1;
    I := 1/(I-1);
  end;
end;

procedure A;
begin
  B;
end;

Danke schon einmal für eure Hilfsbemühungen!

Zitat von Perlsau:

Wie wär's mit einem Breakpoint in der Funktion, in der der Fehler auftritt? Dann stepst du soweit durch, bis der Fehler kommt, und schon hast du ihn am Wickel

Ja, so behelfe ich mir auch immer. Jedoch kann es vorkommen, dass eine Funktion während der Programmausführung ganz oft aufgerufen wird (z.B. in einer Schleife) und nur ganz selten die Exception auftritt, abhängig von irgendwelchen Variablen. Um dann nicht ganz oft unnötig anzuhalten, muss ich mit bedingten Breakpoints arbeiten. Das funktioniert auch meistens sehr gut, ist aber umständlich und für mich keine Dauerlösung.

Zitat:

Der Aufrufstack beinhaltet die Funktion B auch nicht?

Hmm.. nicht wirklich. Gerade habe ich den Fall. Ich tippe gerne mal ab, was da im Aufrufstack steht:

:7654c42d KERNELBASE.RaiseException + 0x58
:00426dca ConvertErrorFmt + $1E
uSTDExport.TSTDExport.exportKData(... Verschiedene Parameter ...)
...

Anhalten tut der Debugger in exportKData(...), die eigentliche Exception wurde aber von einer fehlerhaften Konvertierung in einer Funktion ausgelöst, die von exportKData(...) aufgerufen wird. Der Name dieser Funktion taucht im Aufrufstack nicht auf.

Zitat:

In einem simplen Beispiel passiert das hier zumindest nicht. Der Debugger bleibt exakt in der Zeile stehen, wo die Exception auftritt.

Danke fürs Ausprobieren. Nun weiß ich zumindest, dass es anders sein sollte, und kein neues "Feature" in XE7 ist

Zitat von Sankt Rochus:

Zitat von Perlsau:

Wie wär's mit einem Breakpoint in der Funktion, in der der Fehler auftritt? Dann stepst du soweit durch, bis der Fehler kommt, und schon hast du ihn am Wickel

Ja, so behelfe ich mir auch immer. Jedoch kann es vorkommen, dass eine Funktion während der Programmausführung ganz oft aufgerufen wird (z.B. in einer Schleife) und nur ganz selten die Exception auftritt, abhängig von irgendwelchen Variablen. Um dann nicht ganz oft unnötig anzuhalten, muss ich mit bedingten Breakpoints arbeiten. Das funktioniert auch meistens sehr gut, ist aber umständlich und für mich keine Dauerlösung.

Und wie wär's mit einem Try-Except-Block? Im Except-Bereich könntest du dann eine MessageBox mit der genauen Fehlermeldung zeigen lassen ...

Zitat:

Und wie wär's mit einem Try-Except-Block? Im Except-Bereich könntest du dann eine MessageBox mit der genauen Fehlermeldung zeigen lassen ...

Natürlich kann ich dies und das tun. Es ist und bleibt aber umständlich. Mir geht es nicht um einen konkreten Fall, bei dem ich nicht weiter komme, sondern um ein allgemeines Problem meines XE7-Debuggers.

Zitat von Sankt Rochus:

Anhalten tut der Debugger in exportKData(...), die eigentliche Exception wurde aber von einer fehlerhaften Konvertierung in einer Funktion ausgelöst, die von exportKData(...) aufgerufen wird. Der Name dieser Funktion taucht im Aufrufstack nicht auf.

Kannst du die entsprechende Funktion, die Zeile darin, wo der Fehler auftritt, und die Zeilen, wo die in exportKData aufgerufen wird, mal zeigen?

Zitat:

Kannst du die entsprechende Funktion, die Zeile darin, wo der Fehler auftritt, und die Zeilen, wo die in exportKData aufgerufen wird, mal zeigen?

Kann ich machen. Ich habe hier gerade schon wieder einen anderen Fall, vergiss also bitte exportKData().

Die Funktion exportMedikament(...) ruft TSTDUtils.LittleEndianDateStringToDate(aValue: string): TDateTime auf. Letztgenannte Funktion soll einen speziellen Datumsstring parsen, schlägt aber fehl, da der String dem Datumsformat nicht entspricht. Da die Funtkion exportMedikament(...) sehr umfassend ist, möchte ich nur den Ausschnitt hier zeigen:

Hier die aufrufende Funktion:

markieren

Delphi-Quellcode:

if m_LicenseManager.License.IsLicensed('Patientendaten/Patient/Medikamente/Medikament/Absetzdatum') then
begin
  if ((i = 10) and not l_Zusatz.IsEmpty) then l_Medikament.Absetzdatum := TSTDUtils.LittleEndianDateStringToDate(l_Zusatz); // Hier wird die Funktion aufgerufen und genau hier hält der Debugger
end;

Und hier die Funktion, in der die Exception kommt, in einer anderen Unit, wohlbemerkt:

markieren

Delphi-Quellcode:

class function TSTDUtils.LittleEndianDateStringToDate(aValue: string): TDateTime;
var
  l_CirculatedDateTime: string;
begin
  l_CirculatedDateTime := Copy(aValue, 7, 2) + FormatSettings.DateSeparator + Copy(aValue, 5, 2)
    + FormatSettings.DateSeparator + Copy(aValue, 1, 4);
  if (Copy(l_CirculatedDateTime, 1, 5) = '00.00') then l_CirculatedDateTime := '01.01.' + Copy(l_CirculatedDateTime, 7, 4);
  result := StrToDate(l_CirculatedDateTime); // Hier tritt vermutlich die Exception auf
end;

Die Exception lautet:
".04.2014" ist kein gültiges Datum.

Und hier nochmals der Aufrufstack:

:7654c42d KERNELBASE.RaiseException + 0x58
:00426dca ConvertErrorFmt + $1E
uSTDExport.TSTDExport.exportMedikament(...)
...

Schalt mal die Debug-DCUs ein.