Synchronize und Co. kopieren die Exception und lösen sie im aufrufenden Thread neu aus.

TThread.Execute tut das nicht. Dort ist man selbst verplichtet in OnTerminate, DoTerminate oder nach Beendigung des Threads das Property FatalException zu prüfen.
Hatte das mal bei Borland/Codegear reportet, aber sie hatten wohl keine Lust diese Funktionialität direkt einzubauen (abschaltbar), so daß es keiner vergessen kann.

Kann sein, daß es "früher", in uralten Delphis, nur innerhalb OnTerminate/DoTerminate auslesbar/verwendbar war und danach die Exception sofort freigegeben wurde.
In neueren Delphis wird die Exception via AcquireExceptionObject abgetrennt und bis zum Free ausgehoben.

Hallo zusammen,
erst einmal vielen Dank für die Hilfe!
Nachdem ich zunächst die "Messageboxlösung" ausprobiert habe:

markieren

Delphi-Quellcode:

...
msg:=GetADOErrorString(ADOConnection1);
Messagebox(0,pAnsichar(msg),'ADO-DB Error',MB_OK);

kann ich davon nur abraten, da auch dort manchmal ein Sprung ins Nirwana erfolgt.

Ich hab jetzt den Vorschlag von EMBa eingesetzt und es scheint zu funktionieren.
Wobei so richtig verstanden hab ich es nicht:

markieren

Delphi-Quellcode:

 // Cancel the mouse capture ??
  if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0); {--- wofür soll das gut sein?}
  // Now actually show the exception
  if FException is Exception then {----- warum diese Unterscheidung?}
    Application.ShowException(FException)
  else
    SysUtils.ShowException(FException, nil);

Gruß
K-H

Zitat von p80286:

Wobei so richtig verstanden hab ich es nicht:

markieren

Delphi-Quellcode:

 // Cancel the mouse capture ??
  if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0); {--- wofür soll das gut sein?}
  // Now actually show the exception
  if FException is Exception then {----- warum diese Unterscheidung?}
    Application.ShowException(FException)
  else
    SysUtils.ShowException(FException, nil);

Das WM_CANCELMODE sorgt nur dafür, daß das nachfolgende Fenster auch auf Mausclicks reagieren kann. Es könnte ja sein, daß sich gerade ein anderes Fenster die Maus gekrallt hat. In dem Fall würde zwar die Exception-Meldung angezeigt, der Anwender könnte diese aber nicht mit der Maus wegclicken.

Was die Abfrage danach betrifft: Die Zuweisung nach FException erfolgt durch einen Hard-Cast von ExceptObject . Man kann also nicht sicher sein, daß wirklich eine Exception -Instanz drin steckt. Genau dies wird durch die (auf den ersten Blick unsinnige) Abfrage abgefangen.

Bonus-Wissen: Man kann nicht nur Exceptions raisen, sondern jede Klasseninstanz!

raise TButton.Create(nil); Was auch immer man damit bezwecken will.

Danke, jetzt kann ich das wenigstens alles einschätzen.

schöne Feiertage
K-H

Egal was du machst, dieser Code sollte natürlich besser nur im Kontext des Hauptthreads (VCL) ausgeführt werden.


Für die Zukunft ist es so vorgesehen, daß Exceptions nicht auf der Klasse Exception bassieren müssen, sondern man da auch mal was Anderes einführen kann.

Zitat:

if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0);

ReleaseCapture?

Zitat von himitsu:

Egal was du machst, dieser Code sollte natürlich besser nur im Kontext des Hauptthreads (VCL) ausgeführt werden.

Wird er ja. Die betreffende Methode wird über Synchronize aufgerufen.

Sicherheitshalber erwähnt, so einzeln dastehend ist das nicht erkennbar.

Per Synchronize kann man es nicht anzeigen, denn wenn es knallt, während der Hauptthread hängt, hängt auch die Ausgabe der Exception.
TThread.Queue und dann verzögert anzeigen, wäre da die einzige sichere Lösung, mit den Hausmitteln vom Delphi.