tc39 / proposal-cancelable-promises

Former home of the now-withdrawn cancelable promises proposal for JavaScript
Other
375 stars 29 forks source link

Should cancelling a CancelToken reject its promise, rather than resolving? #69

Closed rictic closed 7 years ago

rictic commented 7 years ago

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:

await Promise.race([cancelToken.promise, otherPromise])

would either yield the resolved value of otherPromise or reject with a Cancel.

/cc @domenic

benjamingr commented 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.

rictic commented 7 years ago

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.

littledan commented 7 years ago

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.

zenparsing commented 7 years ago

@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.

littledan commented 7 years ago

@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?

zenparsing commented 7 years ago

@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