Better error exposure around JobHandle (aka QFuture<std::expected<>>) #926
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
...namely, member functions of the respective job class, or of the result object.
toFutureExpected() doesn't have any users yet.
If the return types are different, then() will now return a future wrapping a std::expected object, instead of failing the build.
With 2-arg then() combining outcomes into a std::expected its implementation is primitive as can be. It doesn't have its users yet though, so tread carefully.
The two facilities to make working with std::expected less verbose. E.g. you can now use `const Expected_Class auto&` or even `JobResult<Room *>` instead of `std::expected<Room *, BaseJob::Status>` for the accepted type.
getDirectChat() has now got the more robust tryGetDirectChat() counterpart; and joinAndGetRoom(), being effectively unused outside of Quotient, changed its signature on the spot.
|
KitsuneRal
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In essence, this PR makes
JobHandleto produce aQFuture<std::expected<...>>thing if you want to propagate errors in the same package as responses. When working directly withJobHandleyou can simply use 2-argthen(); but if you want to take aQFutureout ofJobHandleand only carry the result after letting the job self-destruct, well, here's a way.It is still a bit experimental but after trying it on a couple of methods from
ConnectionI think it makes sense. In Quaternion, I have a blanket error handling, the legacy of very early times - whicheverrequestFailed()occurred, a single handler processes it. Although all new requests automatically get this blanket error handling, I can't specialise it for specific requests. This PR allows me to add error reporting and handling on the spot without having to stick withJobHandles. And actually, one such case even pre-dates this PR:Room::upgrade()already returnsQFuture<std::expected<...>>and using that is very organic I believe.Opinions welcome.