Suggested Preference for ReturnCode vs Signals in Cross-Thread calls
Ok just wanted to know what general preferences are in terms of using return codes or signals to communicate result of an async function call.
So this is how my code currently stands.
Say you have a Login() function that's meant to be threaded. I have it return void
Now at the end of this function I have a signal such as
@void LoginComplete(CustomEnumType returnCode);@
I connect to this signal from the caller with a Qt::QueuedConnection. To call the function I use QtConcurrent::run
Now when this signal fires, In the caller at the connected slot, I check the return code and check if it's kSuccess or returned an error and proceed accordingly.
Now the above process works perfectly fine. However with the concept of
Do not have functions return anything if successful and throw an exception if an error occurs thereby removing return-codes
principle what one can do is something like
Use a QFuture and QFutureWatcher in the caller to connect to the finished() signal of QFuture for normal operations and if there was an error, then emit the LoginComplete(...) signal with the error-code.
Remove the LoginComplete(...) signal all-together and just throw the errorCode from the Login(...) function. What this results to however is a bunch of try catch blocks all over your UI code checking and parsing errorCodes. Now if these Exceptions had to be localized / grouped to only show user relevant info from an exception, Your duplicating all this code all across the UI as well than just handle it in your Models.
Now also in both these new options your additionally creating a QFuture and QFutureWatcher which we did not need for the signal only method. These variables are allocated on the heap as well so that their scope is not limited to just the function invoking Login(...)
To me either of these new approaches looks like a whole load of work for not much of a benefit at all. Well just saves you having to check if errorCode is kSuccess when signal fired and act accordingly. Can the above then be termed as just an edge-case where you don't follow the "no return-code" approach especially when it comes to UI programming when localisation and such factors come into play as well?