I have a main application with a global exception handler installed. Now, for some specific exceptions being raised within another thread I want the global exception handler to be invoked. But it does only handle exceptions from the main thread. I also tried the following from within the thread but it does not work either:
RunInMainThread (procedure
begin
raise EExceptionFromWithinThread.Create;
end);
where RunInMainThread just executes the anonymous method given as a parameter in the context of the main thread.
Why doesn't this work? What's the proper way to handle such a situation?
How about this: send a message to the main thread which exception should be raised.
I handled the exception in the thread, saving the message as a common string variable. When the status of the thread changed, I checked the variable in the main thread. Makes for very readable code.
I do this in my framework if you are interested (http://www.csinnovations.com/framework_overview.htm).
Related
WinForms (VS2015 / .NET 4.6)
In my background thread
System.Threading.Tasks.Task.Run(() =>
{
...
_callback?.Progress("abcd");
...
});
I call the GUI (_callback), which implements an interface in the Form class.
Here, I modify textbox, progressbar, etc values.
void IWorkerCallback.Log(string message)
{
_textBoxLog.AppendText($"{message}{Environment.NewLine}");
++_progressBar.Value;
.... etc...
}
And all works fine!
If I break in with debugger, I could see that the Form.IWorkerCallback.Log() function is executed in the worker thread context (in Threads debug window).
It's said everywhere that you MUST change GUI items only on the GUI thread (where they are created), otherwise you get System.InvalidOperationException exception with cross-thread operation not valid.....
But it works fine for me.
Could you explain, why?
Thanks
Running UI calls from another thread is undefined behavior. It may work or not. To get consistent failure on cross-thread calls set Control.CheckForIllegalCrossThreadCalls = true; in the beginning of the program:
https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.control.checkforillegalcrossthreadcalls?view=netframework-4.8
From MSDN documentation:
When a thread other than the creating thread of a control tries to access one of that control's methods or properties, it often leads to unpredictable results. A common invalid thread activity is a call on the wrong thread that accesses the control's Handle property. Set CheckForIllegalCrossThreadCalls to true to find and diagnose this thread activity more easily.
On low Windows API level, cross-thread UI calls that don't use thread local storage or any other thread-specific resources, may be executed successfully. However, we still have thread synchronization problem, so result is also undefined.
We have 2 applications, the first one is VCL project, the other is a windows service.
In the VCL project we do:
try
except
on E: Exception do
// do something with E.Message
end
but in the windows service (which uses several threads) we use:
try
except
// do something with Exception(ExceptObject).Message
end
The information I got from my coworkers is that "We must use ExceptObject in threads and E: Exception in applications that use GUI". But I couldn't find anything regarding this.
I found an example here http://edn.embarcadero.com/article/10452 where it uses an instance variable to store the exception and it uses the ExceptObject, but gives no explanation why.
Is this ExceptObject even thread-safe (since it comes from the unit 'System')?
So what is the right way to handle exceptions in Delphi and why is there more than one way to do it?
There is no right way for exception handling. There is just one way. What might confuse you could be dealing with the exception object which is created, and which causes an exception to raise, but whose lifetime is the most important for you here.
In general, there's only two ways of dealing with those exception objects. Either you let them alive beyond the exception block scope and release them by yourself or let them free by the RTL when the exception block ends.
But to answer what I guess you've asked. Exception class isn't thread safe. And, your coworkers were wrong as no one is forced to use specific exception handling in threads. These rules are the same for all threads created by the process, no matter what. Just, those exception objects can be unstable within exception blocks:
1. Get the current exception object from the ExceptObject
The ExceptObject returns the current exception object. In practice, it may cause this; if you store such object reference into a variable inside an exception handler block and another exception will get raised within such block, that stored instance may become invalid. Which is quite unsafe.
But it doesn't mean you could not take a reference of such object and pass it to another thread by using some synchronization mechanisms (since it's not a thread safe class) and work with it there. You just need to take care that no other exception will be raised because that would invalidate the previously stored object so as you must take care of staying inside the exception handler from the caller's point of view and you must use a kind of thread synchronization mechanism.
So actually working with the exception object acquired from an on expression can be more stable than using ExceptObject. But the same rules applies here as well; you'd need to synchronize the object instance from the on expression with another thread (since it's not a thread safe class), but in such case, object acquired from the on expression won't get changed unlike the ExceptObject one can be within a certain exception block.
2. Retain exception object by using AcquireExceptionObject
The AcquireExceptionObject function allows you to keep the exception object alive even out of the exception block.
For an exception handling when speaking about thread synchronization, I'd suggest you using the AcquireExceptionObject function which makes the exception object free to consume, even after the exception block ends. For you that brings the only responsability, free such acquired object by calling the ReleaseExceptionObject procedure or raising the exception by this object again.
Victoria is absolutely correct.
Personally, I have a strong preference for this idiom:
try
...
except
// IO error
On E : EInOutError do
ShowMessage('IO error : '+E.Message);
// Division by zero
On E : EDivByZero do
ShowMessage('Div by zero error : '+E.Message);
// Catch other errors
else
ShowMessage('Unknown error');
end;
To elaborate:
Victoria said "There is no right way for exception handling. There is just one way." That's absolutely correct.
The advice you got about "use one syntax for threads, and the other for GUIs" is simply wrong. There is no "different syntax" for "threads" vs. "GUI". That's nonsense :(
I prefer using on : MyExceptionType in an exception block.
I also prefer to differentiate different exception types, whenever/wherever possible.
The example you cited, http://edn.embarcadero.com/article/10452, deals with how to avoid a possible access violation if you don't handle the exception within that particular thread. Saving the exception instance in a member variable helps mitigate this problem.
The following link might help clarify:
http://www.delphibasics.co.uk/Article.asp?Name=Exceptions
I'd like to be able to handle an async exception in thread A such that if another thread B calls throwTo, that call blocks until my handler in A has a chance to finish. As I understand it throwTo only blocks until the exception is "received".
I thought maybe some clever use of uninterruptibleMask might help me, but I'm stumped.
EDIT: I just noticed this:
The difference between using try and catch for recovery is that in
catch the handler is inside an implicit block (see "Asynchronous
Exceptions") which is important when catching asynchronous exceptions, ...
I thought that might be suggesting that catch would actually do what I'm looking for (I was using onException), but that doesn't seem to be the case. So as an additional question: what is meant by "the handler is inside an implicit block" here?
At the moment, I am using WaitForSingleObject to wait for a sub-task thread to complete. Unfortunately, this causes my GUI to lock up. What I would like to do instead, is set a handler (in the GUI thread) that will be called after the sub-task thread is complete. Is there another function for this?
What you can do is to let the last thing that your thread does be posting a custom message to your window. Then handle that as a regular message using MFC's message map. If you cannot change the thread code, you can create a new thread that waits for your thread and then sends the message.
As you already noticed, it is not a good idea to lock up the GUI thread...
Edit: Posting the message is done using the PostMessage function as pointed out by Hans in the comments.
Could also have a look at MsgWaitForMultipleObjects (or MsgWaitForMultipleObjectsEx).
These allow a thread to wait for event handles and service windows messages (examine the return value to see what causes the call to return). Examples of usage should be available via a goodle search.
http://msdn.microsoft.com/en-us/library/ms684245(VS.85).aspx
I am having a problem with some code that was written by a developer that has now left our company, the code implements a tcpserver that responds to an XML based protocol. This appears to be working absolutely fine in our test environment but one or two customers are having problems with application shutdown.
I have traced this to what appears to be a deadlock when tidtcpserver.active = false is called. I am already aware that a deadlock can be caused by one of the connection treads making a synchronised call to the main thread, whilst the main thread is waiting for the connection threads to terminate.
I am already using a tidthreadsafestringlist to pass the data to the main thread for processing, and where I need to call a procedure from the main thread I have created a tidnotify descendant to do this. can anyone think of anything else to look for.
I had already been checking the exception handling,
this is what i have in the onexecute event
try
// code to handle connection including tidnotify etc....
except
on E:Exception do
begin
if (e.InheritsFrom(EIdSilentException) = False) then
TXMLTraceNotify.XMLTrace('TCPServerExecute: ' + E.Message,ttProblem, FTraceProc);
raise; //we must raise all exceptions for indy to handle them.
end;
end;
Here is how i'm using the TS-stringlist
Declaration.
public
TransactionStrings: TIdThreadSafeStringList;
its created in the constructor and destroyed in the destructor.
this is how i'm adding to it in the context of the tcpserver.
TransactionStrings.Add(newTrans.AsString);
And this is how i'm reading from it in the context of the main application thread
slXMLTrans := TStringList.Create;
try
slTemp := FCustomXMLServer.TransactionStrings.Lock;
try
slXMLTrans.Assign(slTemp);
slTemp.Clear;
finally
FCustomXMLServer.TransactionStrings.Unlock;
end;
if slXMLTrans.Count > 0 then
begin
for i := 0 to Pred(slXMLTrans.Count) do
TAbstractTerminal.ProcessXMLTrans(slXMLTrans[i]);
slXMLTrans.Clear;
end;
finally
slXMLTrans.Free;
end;
I think this is the correct way to use it but I await your comments.
Deadlocks when setting the Active property to False are a classic, and often discussed, issue when using TIdTCPServer incorrectly. The only way the server deadlocks is when the connection threads do not terminate correctly. That MAY be caused by synchronizing operaton to the main thread while the main thread is busy deactivating the server, in which case the use of TIdNotify would does eliminate any such deadlock conditions.
However, that is not the only way to prevent a connection thread from terminating. Another possibility is if your server event handlers have exception handling in them that is blocking Indy's internal notifications from being processed. That can cause runaway threads that keep running but never know that they need to stop. If you are catching exceptions in your code, make sure you re-throw any EIdException-derived exceptions and let the server handle them internally.