How to catch exceptions in a thread? - multithreading

Question

My web server is based on Delphi / DataSnap.
When a server method raises an exception, how can I handle it?
I tried Application.OnException but it does not work because each connection is a new thread and it only works for the IDE thread.
I want to manage them for adding the data in a log file.
UPDATE:
As #Remy Lebeau says, I do not have control aver the creation of the thread. It is a DataSnap based application that works as Web Api server. A TDSServerClass components instances my TServerMethods class. Then, when a web connection arrives, DataSnap creates a new thread and call to my TServerMethods methods. If within the method, a exception is raised, then it is lost because each thread has its stack. With Application.OnException, I only can catch unhandheld exceptions from the IDE thread. What I want to do is to log any handheld exception in a log file.

Answer 1

From the System.Classes.TThread.FatalException documentation:
If the Execute method raises an exception that is not caught and handled within that method, the thread terminates and sets FatalException to the exception object for that exception. Applications can check FatalException from an OnTerminate event handler to determine whether the thread terminated due to an exception.
If an exception occurs in the Execute method of a TThread object its FatalException property is assigned and the thread terminates.
You can check if an exception occurred in a thread implementing its OnTerminate event:
procedure TForm1.YourThreadTerminate(Sender: TObject);
var
ex: Exception;
begin
ex := Exception(TYourThread(Sender).FatalException);
if Assigned(ex) then
//an exception has occurred: your code here
end;
This is how you can assign the event to you thread:
var
yourThread: TYourThread;
begin
yourThread := TYourThread.Create(True);
yourThread.OnTerminate := YourThreadTerminate;
yourThread.Start;
end;

Answer 2

You may need to hook into the exception handling mechanism itself - JCL has code that does that, for example, or you could use third party libraries like madExcept, EurekaLog or others. They also collect stack traces and other info useful to understand what lead to an exception.
I used JCL some time ago in a Datasnap DCOM server to log unhandled exception to a custom event log. If you're going to write to a file, beware of concurrent access, because more than one thread could try to write to it. Also Event Tracing for Windows (ETW) may be a a better, although more complex way, to log to a file for diagnostic purposes.
Anyway, in this kind of applications, it's better to handle "expected" exceptions, and never let them propagate up to a generic handler. Of course, being able to trap and log "unexpected" ones is useful.