Closed rictic closed 7 years ago
I disagree, the promise
is waiting for cancellation. Rejecting it might mean cancellation is no longer possible but represents an exceptional situation. A token being activated isn't exceptional.
Semantically I can see the argument that the promise should resolve, but ergonomically I don't think it's great. My assumption (and this is true of the code written with cancellation so far) is that when some work is cancelled you'll want to abruptly processing rather than continuing normally or returning. Promise rejection makes that easy, resolution makes it awkward.
Are there any examples of where a cancellation would no longer be possible? If there are use cases there then that may override the ergonomic argument for me.
I agree that this should lead to rejection. It's important that the cancellation trigger non-locally jumping out of code, rather than "succeeding" with a value that's just unexpected. This looks to me like a spec bug.
@littledan If token.promise
is used to attach a cancellation listener, then it must be resolved, and not rejected. This would be confusing:
async function f(token) {
token.promise.catch(reason => {
// Catch? That's strange : )
});
}
But I think this just points to the idea that a promise is not the most ideal way to model a cancellation event.
@zenparsing Do you have a particular API that you would prefer? I see old es-discuss threads where you've proposed something similar to this proposal; what are your current thoughts?
@littledan Under the circumstances it feels odd to link out, but oh well. Here's what I was playing with: https://github.com/zenparsing/es-observable-cancellation
If I'm reading this correctly, CancelToken#promise is resolved when the token is cancelled: https://tc39.github.io/proposal-cancelable-promises/#sec-cancel-cancel-token
It seems more natural that it would reject, so that stuff like:
would either yield the resolved value of
otherPromise
or reject with aCancel
./cc @domenic