Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

why does syncWait.assumeOk throw when calling onDone? #75

Open
WebFreak001 opened this issue Mar 8, 2023 · 3 comments
Open

why does syncWait.assumeOk throw when calling onDone? #75

WebFreak001 opened this issue Mar 8, 2023 · 3 comments

Comments

@WebFreak001
Copy link

WebFreak001 commented Mar 8, 2023

DoneSender().syncWait.assumeOk.shouldThrow();

I don't get why this test code passes - DoneSender should just make the task finish without value, while ThrowingSender makes it error/abort.

Why does the test check for assumeOk.shouldThrow throw like ThrowingSender?

@WebFreak001 WebFreak001 changed the title why does DoneSender throw? why does syncWait.assumeOk throw when calling onDone? Mar 8, 2023
@skoppe
Copy link
Collaborator

skoppe commented Mar 9, 2023

Yeah, I am on the fence here.

With Senders there are 3 termination points: natural completion, completion due to cancellation and error. assumeOk only counts natural completion as correct, and errors out on the other 2.

DoneSender is a bit of a misnomer I guess, CancelSender would have been a bit better.

@WebFreak001
Copy link
Author

onDone should probably also be called onCancel then I think?

@skoppe
Copy link
Collaborator

skoppe commented Mar 10, 2023

onDone should probably also be called onCancel then I think?

Its actually called setDone. Emphasize on completion.

One thing about cancellation is that in terms of lifecycle its important to know when the cancellation is done. Its only when it is done that resources can be cleaned.

Senders signal completion, so the setValue, setDone, setError trifecta actually makes sense. And contrary to what I said yesterday, that makes DoneSender actually the more correct naming.

Sorry, the concurrency stuff has moved to the back of my mind a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants