XE7 Debugger hält bei Exception eine Funktion darüber an.

[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

[CarlAshnikov]

Der Aufrufstack beinhaltet die Funktion B auch nicht?

[Sankt Rochus]

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

[Perlsau]

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

[Uwe Raabe]

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?

[Sankt Rochus]

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:

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:

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(...)
...

[Uwe Raabe]

Schalt mal die Debug-DCUs ein.

[Sankt Rochus]

Zitat:

Schalt mal die Debug-DCUs ein.

Super! Ich habe gerade eine Exception nachgestellt. Jetzt lande ich beispielsweise bei einer fehlerhaften Konvertierung sogar direkt im ConvertErrorFmt(...), von wo ich mich dann im Aufrufstack hoch hangeln kann über StrToInt() direkt zu meiner Exception auslösenden Funktion. Ich hoffe, dass das die Ursache war, und es jetzt nicht nur ausnahmsweise funktioniert Jetzt macht Delphi wieder Spaß

Vielen Dank dir Uwe!